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PREFACE 


This document establishes the functional requirements for the MODIS Information, Data, 
and Control System (MIDACS). The purpose of the MIDACS Functional Requirements 
Document is to provide a basis for the mutual understanding between the users and the 
designers of the EosDIS, including the requirements, operating environment, external 
interfaces, and development plan. In defining the requirements and scope of the system, 
this document will describe how MIDACS will operate as an element of the EOS within 
the EosDIS environment. This version of the Level-II Requirements Document follows the 
earlier release of a preliminary draft version. The sections on functional and perfor- 
mance requirements do not yet fully represent the requirements of the data system 
needed to achieve the scientific objectives of the MODIS instruments and science team. 
Indeed, the team members have not yet been selected and the team has not yet been 
formed. However, it has been possible to identify many relevant requirements based on 
the present concept of EosDIS and through interviews and meetings with key members of 
the science community. These requirements have been grouped by functional component 
of the data system, and by function within each component. These requirements have 
been merged with the complete set of Level-I and Level-II context diagrams, data flow 
diagrams, and data dictionary. 

The study team is indebted to: Wayne Esaias, Chris Justice, and Joel Susskind for 
detailed information regarding the science requirements; Bill Barnes, John Barker, and 
Bruce Guenther for information regarding MODIS instrument concepts; H. Lee Kyle, and 
Dick Stonesifer for their insight into aspects of data processing, instrument control, and 
data storage; and to A1 Fleig for his assistance in applying the guidelines being set forth 
by EosDIS. 
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GENERAL INFORMATION 

SUMMARY 


f 


1.1 


The Moderate Resolution Imaging Spectrometer (MODIS) is planned to fly on the NASA 
Polar-Orbiting Platform 1 (NPOP-1) as a part of the Earth Observing System (EOS) beginning 
in the mid-1990’s. The MODIS Instrument is expected to be composed of two components: the 
MODIS-T, for a "tillable" cross-track scanner, and the MODIS-N for a nadir viewing cross- 
track scanner. As currently envisioned, the instruments shall provide multi-year, continuous 
terrestrial coverage across a 1780-kilometer swath with 104 channels covering the visible, 
near-infrared, and thermal infrared spectral regions. The channels have been selected to 
provide land-science, oceanographic, and meterological observations at spatial resolutions 
ranging from one kilometer to 250 meters at nadir. 

As a consequence of the design of MODIS, a high data rate and an extremely large data 
archive volume are anticipated. Furthermore, specific aspects of the EOS Data and Informa- 
tion System (EosDIS) combine to shape the processing requirements for the MODIS data 
system; in particular, the release of certified data products in accessible archives within 48 
hours of real time. 

1.1.1 Purpose 

This document establishes the functional requirements for the MODIS Information, Data, and 
Control System (MIDACS). The purpose of the MIDACS Functional Requirements Document is 
to provide a basis for the mutual understanding between the users and the designers of the 
EosDIS, including the requirements, operating environment, external interfaces, and develop- 
ment plan. In defining the requirements and scope of the system, this document will describe 
how MIDACS will operate as an element of the EOS within the EosDIS environment. 

1.1.2 Scope 

The MIDACS fulfills the responsibilities of instrument monitoring and control, as well as data 
acquisition, management, production, certification, and distribution. In order to design the 
MODIS data system to efficiently and reliably fulfill each of these functions, the system’s 
functional, performance, and other requirements must be clearly stated. It is recognized that 
the requirements of the MODIS data system will evolve as information is compiled, the science 
team formed, and the instrument design refined. This requirements document will evolve in 
response to evolutions in the scientific requirements. In this first draft, not all requirements 
are fully addressed: some specific requirements are identified, yet left undefined; these will be 
completed in later drafts. 

1.1.3 Organization of the Document 

The MIDACS Functional Requirements Document is organized into nine sections. Section 1 
provides the reader with general information relating to the MODIS data system, including 
standards and applicable references. Section 2 provides an overview and functional description 
of the MODIS Data System. The system overview concentrates on major functional aspects of 
EosDIS as they relate to MODIS, while the functional description of the data system empha- 
sizes the specific areas internal to MIDACS. Section 3 states the functional requirements of 
all aspects of the MIDACS, and emphasizes the Instrument Support Terminal (1ST), the 
Instrument Control Center (ICC), the Central Data Handling Facility (CDHF), the Team 
Member Computing Facility (TMCF), and the Data Archive and Distribution System (DADS). 
Section 4 states the performance requirements. Section 5 addresses the interfaces between 
MIDACS and the outside world, termed external, which include specific aspects of the EosDIS 
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as well as other users. Sections 6, 7, and 8, respectively, discuss the physical requirements, 
delivery and installation requirements, and design and implementation constraints of the 
MIDACS. The development plan for the MODIS Data System is documented in Section 9. 

Finally, Section 10 contains the appendices listing acronyms, the set of assumptions employed 
in developing this set of functional requirements, the MODIS Data System Dictionary, and data 
rate, volume, storage, and processing considerations. 

1.1.4 Standards 

The following standards will be followed during the MIDACS development cycle: 

a. Software Engineering Standards 

b. Operating System Standards 

c. Common Operating System/Exceptions 

d. Coding and Software Implementation Standards 

e. Standard Media and Protocols 

f. Programming Language Standards 

g. Standard Formatted Data Unit 

h. Other Standards 

1.2 REFERENCES AND APPLICABLE DOCUMENTS 

1. Earth Observing System Data and Information System Requirements, Level I, 
NASA/GSFC, March 15, 1988 

2. Eos Control Center Requirements, Memo from Steve Tompkins, NASA/GSFC Code 
511, October 28, 1987 

3. EosDIS Baseline Report, Draft #2, CTA, May 26, 1988 

4. EosBIP, Part Three, Eos Science, Operations, and Data Management, January 19, 

1988 

5. Earth Observing System Data and Information System Requirements Analysis Report, 
CTA, April 1987 

6. Earth Observing System Data and Information System Report of the EOS Data 
Panel, Volume Ila, NASA, 1986 

7. An Operation Concept and Information System for the Earth Observing System CTA, 
January 1985 

8. MODIS (Moderate-Resolution Imaging Spectrometer) Instrument Panel Report, NASA, 
Volume lib, 1986 

9. Phase A Study Report For the Moderate Resolution Imaging Spectrometer Data 
System, Level-1 Processing (Draft), SAR 

10. EosDIS Control Center Concepts V2.1 February 25, 1988 

11. EosDIS Interface Definition Document, (Draft) CTA, May 11, 1987 

12. HIDACC Functional Requirements Document - Preliminary Version 1.0, JPL, 
December 21, 1987. 
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13. System Specifications for The Space Telescope (ST) Data Archive and Distribution 
Service (DADS), Computer Sciences Corp. 

14. Moderate Resolution Imaging Spectrometer-Nadir (MODIS-N) Specification for a 
Phase-B Study. NASA Goddard, Nov. 10, 1987. 

15. From Pattern to Process: The Strategy of the Earth Observing System. Eos Science 
Steering Committee Report. Vol. II. NASA/GSFC. 

16. MODIS: An Advanced Facility Instrument for Studies of the Earth as a System. V. 
Salomonson et al., 1988. Preprint for IEEE. 

17. Eos Science and Mission Requirements Working Group Report, Vol. I Appendix 
(NASA/GSFC). 

18. MIDACS Data Flow Report by the MODIS Data System Phase-B Study Team. 

19. Quick-Look Data Requirements of the MODIS Instrument Team, the MODIS Data 
System Study Team, October 7, 1988. 

20. MIDACS Preliminary Operational Concept, MODIS Study Team, September 1988. 

2. OVERVIEW AND SYSTEM DESCRIPTION 

This section addresses the environment and context within which the MIDACS will operate, 
and provides a general description of the MIDACS as a system and the EosDIS elements that 
MIDACS will interact with. 

2.1 SYSTEM OVERVIEW 

MODIS has been designated as a facility instrument on the first NASA polar orbiting platform, 
NPOP-1, scheduled for launch in 1995. It is the responsibility of NASA to provide a ground 
system by that time which will control the operation of the MODIS instrument on board the 
platform and perform the data acquisition, monitoring, processing, and distribution functions to 
serve the user community. 

NASA’s Goddard Space Flight Center (GSFC) is responsible for the design and development of 
the MODIS ground system. This ground system, called the MODIS Information, Data, and 
Control System (MIDACS), will be one of the elements operating in the context of the overall 
EosDIS. The EosDIS will be responsible for the end-to-end data flows involving the EOS 
Platform Data System, MODIS Instrument Data System on board the platform, the Tracking 
and Data Relay Satellite System (TDRSS) and its ground terminals at White Sands, the various 
EOS ground systems, and the users. Figure 1 describes the EosDIS environment under which 
the MIDACS will operate. The following sections provide a brief description for each of the 
systems in the EosDIS and MIDACS environments. 

2.1.1 MODIS Instrument 

The MODIS instrument will be on the EOS platform NPOP-1 that has a nominal altitude of 824 
km, an inclination of 98.7° to maintain a Sun-synchronous orbit, and a period of approximately 
101 minutes. The instrument is expected to cover 104 spectral bands in the range of 0.4 to 
14.2 microns. MODIS will be divided into two sensors designated as MODIS-N (nadir) and 
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Figure 1. The MODIS Data System in the EosDIS Environment 
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MODIS-T (tilt). The instrument is expected to have a data rate of from 2 (night) to 17 (day) 
Mbps. The long-term average data rate is anticipated to be about 10 Mbps. 

2.1.2 MODIS Instrument Data System 

The MODIS Instrument Data System will be one of many instrument data systems on the 
NPOP-1, each of which would provide similar functions to support an instrument. 

2.1.3 EOS Platform Data System 

The Eos Platform Data System provides the common monitor and control of all instruments on 
the platform. In addition, it provides the common services (communication, power, etc.) for 
all instruments. 

2.1.4 TDRSS Ground Terminal (TGT) 

The TDRSS provides the uplink and downlink capability for the EOS platform. On the 
average, a platform should have access to the TDRSS for about one-third of its orbit. 

2.1.5 Data Interface Facility (DIF) 

The Data Interface Facility (DIF) provides data communication, data buffering, and data 
routing between the TDRSS ground terminal and the ground data network. It is the gateway 
between the space network and ground data network. 

2.1.6 Data Handling Center (DHC) 

The Data Handling Center (DHC) is responsible for Level-0 processing of low-rate data to 
remove any artifacts introduced into the data by the transport system. As data leaves this 
function it should look as it did when it left the instrument. 

2.1.7 Eos Mission Operations Center (EMOC) 

The Eos Mission Operation (EMOC) provides the coordination required to allocate resources 
for, and schedule and command the many instruments which fly on, the Eos platforms. 

2.1.8 Platform Support Center (PSC) 

The PSC is a proposed GSFC facility under the Customer Data and Operations System (CDOS) 
that will provide mission control support for a variety of space programs at GSFC. The PSC 
will perform standard control center functions to monitor and control the platform operations. 
The PSC will be involved in the planning and scheduling functions for EOS payloads, as well 
as in all aspects of planning, scheduling, commanding, and telemetry monitoring of the 
platform core. 

2.1.9 Information Management Center (IMC) 

The Information Management Center (IMC) is the central data management facility for the 
EosDIS. Its principle functions are to provide the users with a mechanism for placing orders 
for products and to accommodate the user with information as to where the particular data 
products are stored. 
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2.1.10 National Space Science Data Center (NSSDC) 

The NSSDC will serve as a long-term permanent archiving and distribution center for data 
obtained on NASA Space and Earth Science flight investigations. The NSSDC will develop and 
perform a variety of services to enhance the scientific return in these missions. The data 
sets archived will contain high-level information. The NSSDC is not a part of EosDIS. 

2.1.11 Discipline Data Center (DDC) 

The various discipline data centers (DDCs) (i.e., NASA Ocean Data System (NDOS), NASA Land 
Data System (NLDS), and NASA Climate Data System (NCDS)) are responsible for providing 
research scientists with disciplinary areas. These DDCs, although not part of the EosDIS, will 
receive MODIS products from the MIDACS. 

2.1.12 Users 

The MIDACS will interface with both GSFC local and remote users. They are classified here 
as the instrument team leader and members and other various science teams. The MODIS 
products will support research scientists of the following disciplines: ocean, land, and 
atmosphere. 

2.1.13 External Interfaces 

Figure 2 provides a context diagram of the MIDACS and shows the interfaces with the 
external elements. 

2.2 FUNCTIONAL DESCRIPTION OF MIDACS 

Figure 3 depicts the internal systems within the MIDACS and their interfaces. The following 
sections are a list of internal centers of MIDACS and the respective functions which support 
the MODIS instrument. 

2.2.1 Instrument Support Terminal (1ST) 

The 1ST is essentially a workstation connected to the ICC. It gives the team leader or 
members access to the engineering data or quick-look science subset of a payload in order to 
support instrument integrity functions and/or to initiate commands and plans for specialized 
conditions. The 1ST Context Diagram is provided in Figure 4. 

2.2.2 Instrument Control Center (ICC) 

This center is responsible for the ground control of the operation of the MODIS instrument on 
board the platform. The ICC will support the instrument planning, scheduling, commanding, 
and status monitoring of MODIS. The ICC Context Diagram is provided in Figure 5. 

2.2.3 Team Member Computing Facility (TMCF) 

A scientist team member will be responsible for the development and maintenance of the 
algorithms for the production of data sets. The TMCF will be distributed and will provide 
computing resources at research instrument team member locations to be used in the develop- 
ment and test of algorithms, the productions of data sets, and the assessment of data quality. 
The TMCF Context Diagram is provided in Figure 6. 
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Figure 3. MIDACS Element Functional Allocation Diagram 





Figure 4. The 1ST Context Diagram 
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Figure 5. The ICC Context Diagram 
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Figure 6. The TMCF Context Diagram 



2.2.4 Central Data Handling Facility (CDHF) 

The CDHF has the responsibility of receiving instrument data, and processing and generating 
useful products for the user at predetermined levels of processing. The levels of data to be 
produced include Level-IA (reversible to Level-0), Level-IB (calibrated and Earth-located 
radiances), Level-2 (geophysical parameters), Level-3 (gridded and averaged products), and 
Level-4 (comparisons to non-MODIS products). The CDHF Context Diagram is provided in 
Figure 7. 

2.2.5 Data Archive and Distribution System (DADS) 

The DADS will provide for the ingest and temporary storage and management of processed 
data sets, catalogs, and directories for data processed by the CDHF and others. It 
provides an interface to the users for distribution of requested products and archiving of data 
to a permanent archive. The DADS Context Diagram is provided in Figure 8. 

3. FUNCTIONAL REQUIREMENTS 

FNRl: The MODIS data system shall support atmospheric, oceanographic, and land 
science field experiments by providing near-real-time processing of MODIS data. SOURCE: 
Reference 19. 

FNR2: A center will need to have the capability to trace the data flow back through 
the processing system to the instrument, aiding in the isolation and correction of problems. 
SOURCE: Reference 6, page 2. 

FNR3: Careful consideration should be given to standard format structures for data 
interchange. SOURCE: Reference 6, page 14. 

FNR4: Any standard adopted under the EOS infosystem auspices should take machine and 
data independence practices into account. SOURCE: Reference 6, page 13. 

3.1 INSTRUMENT SUPPORT TERMINAL (1ST) 

[See Data Flow Diagram 1.0: 1ST Functional Data Flows] 

FNR5: The 1ST shall provide the MODIS team leader with the capability to monitor 
MODIS from a home institution while maintaining access security. SOURCE: Reference 2 (1ST 
Facility and Reference 3). 

FNR6: The 1ST functions shall include procedure generation, anomaly investigation, 
operations monitoring, and possibly commanding (via requests to the ICC). SOURCE: Refer- 
ence 2 (1ST Facility). 
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Figure 7. The CDHF Context Diagram 
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Figure 8. The DADS Context Diagra 
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DFD 1.0 1ST Functional Data Flows 


3.1.1 Observation Planning and Coordination 

[See Data Flow Diagram 1.1: Provide Observation Planning and Coordination] 

FNR7: The MODIS team leader shall be responsive to observation planning requests of 
the MODIS instrument from multi-disciplinary scientific entities. SOURCE: Reference 1 
(derived from 2.1.1c). 

FNR8: The MODIS team leader shall be responsive to requests from international entities 
for planning cooperative observational efforts of the MODIS instrument. SOURCE: Reference 
1 (derived from 2.1.d). 

FNR9: The MODIS team leader shall routinely collect and prioritize observation requests 
and shall regularly transmit such requests to the ICC for scheduling and command implementa- 
tion. SOURCE: Reference 4 (Sections 3.2.2(5), 5.2 and 5.4.4). 

3.1. 1.1 Planning Data 

FNR10: The 1ST shall receive and format science planning information from the MODIS 
users community, from MODIS team members, and from the ICC. SOURCE: Reference 18, 1ST 
Context Diagram and DFD 1.1. 

3. 1.1. 2 Observation Plan Coordination 

FNR11: The 1ST shall formulate a prioritized and coordinated MODIS observation plan 
from the received planning inputs. SOURCE: Reference 18, DFD 1.1. 

FNR12: The 1ST shall be responsive to requests for science plan information from the 
user community. SOURCE: Reference 18, 1ST Context Diagram and DFD 1.1. 

FNR13: The 1ST shall coordinate a request from a MODIS team member for priority 
handling designations for specific MODIS observation data. SOURCE: Reference 18, 1ST 
Context Diagram and DFD 1.1. 

3.1. 1.3 Observation Requests 

FNR14: The 1ST shall convey formatted observation requests to the ICC. SOURCE: 
Reference 18, 1ST Context Diagram and DFD 1.1. 

3.1.2 Instrument Performance Evaluation 

[See Data Flow Diagram 1.2: Monitor Instrument Performance] 

FNR15: The MODIS team leader shall support the indoctrination and periodic training of 
ICC and 1ST personnel. SOURCE: Reference 1 (derived from 2.1. If). 

FNR16: The MODIS team leader shall define and test the MODIS operational scenarios 
and provide direction to the ICC for proper monitoring of the MODIS operation. SOURCE: 
Reference 4 (derived from 5.4.5). 

3.1. 2.1 Instrument State-o {-Health Analysis 

FNR17: The 1ST shall provide an assessment of the ongoing MODIS performance. 
SOURCE: Reference 4 (5.4.4). 
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DFD 1.1 Provide Observation Planning and Coordination 
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DFD 1.2 Monitor Instrument Performance 


FNR18: The MODIS status indicators available at the ICC shall be available at the 1ST. 
SOURCE: Reference 4 (5.4.4). 

FNR19: The 1ST shall send requests to the ICC for special calibration modes or changes 
in source parameters such as blackbody temperatures or a change in lamps. SOURCE: 
Reference B. Markham. 

FNR20: The 1ST shall monitor MODIS operation to detect and react to uncharacteristic 
changes in detector response. The MODIS team leader and team members shall investigate 
such anomalies and recommend MODIS configuration and operational procedure changes to 
support the investigation. The 1ST shall approve MODIS operational changes to accommodate 
continued data collection. SOURCE: Reference 3 (5.2.2). 

3.1. 2. 2 Instrument Model Parameters Maintenance 

FNR21: The 1ST shall maintain a quick-look data set which bears on the calibration of 
the instrument, primarily to identify unexpected calibration changes which would affect the 
routine data processing. This data set shall provide the status of the onboard sources, their 
recent history, and the current and recent history of the instrument responses to the calibra- 
tion sources. SOURCE: Reference B. Markham. 

FNR22: The 1ST shall maintain an on-line summary of calibration coefficients presently 
being used in the routine data processing. SOURCE: Reference J. Barker. 

3.2 INSTRUMENT CONTROL CENTER (ICC) 

[See Data Flow Diagram 2.0: ICC Functional Data Flows] 

FNR23: The MODIS Science Team shall use the ICC for operations. SOURCE: Refer- 
ence 2 (ICC Facility). 

3.2.1 Observation Planning and Scheduling 

[See Data Flow Diagrams 2.1: Plan and Schedule Observations] 

FNR24: The ICC shall have interactive control of the MODIS scheduling simulator from 
a console in the ICC. SOURCE: Reference 2 (ICC Facility) and derived from Reference 5, 
Req. 317. 

FNR25: The ICC shall provide coordination with authorized users (via the 1ST) in devel- 
oping MODIS operation schedules. SOURCE: Reference 2 (ICC Facility). 

3.2.1. 1 Observation Requests 

FNR26: The ICC shall receive observation planning and scheduling information in the 
form of a generic MODIS science plan from the IST/EMOC, an iterated schedule from EMOC 
and specific observation requests from the 1ST. This information shall be formatted into a 
sequence of observation requests. SOURCE: Reference 18, ICC Context Diagram and DFD 2.1. 

3.2.1.2 Instrument Time-Line Generation 

FNR27: The ICC manner of scheduling instrument activities shall accommodate changing 
user requirements, platform operating capabilities, satellite/Earth/Sun geometries, and cloud 
cover. SOURCE: Reference 2 (ICC Facility). 
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DFD 2.0 ICC Functional Data Flows 



Schedule-Data 


© « « 
c« eS 2 

p £ i 

all. 


f LU LU |_ 
H rA CO 
Tj- < Z) LJJ 

^ DC Q Q D 


^ LU LU 2 
H O LU 

^05 

Occ£ 



' mEliJ 

t HI 2 

"M 3 

, Ip 


. op 

cvi o CC 2 

LUlijU 
oc CO £ 
CD °C 

^ O ^ 


r , c 

T3 .2 
© ~ <2 
*5 § 0> 
to c e 

E © 3 

O O’ 
O 5 ® 
ii. O cc 


21 



22 



FNR28: The ICC shall verify observation requests from MODIS instrument users. 
SOURCE: Reference 12, p. 7. 

FNR29: Instrument operations shall be in accordance with the schedule defined by the 
EMOC. Deviations without coordinating with the EMOC will occur only in the event of an 
instrument or platform anomaly for which a predefined procedure exists. SOURCE: Reference 
2 (ICC Facility). 

FNR30: The ICC shall have the capability to simulate MODIS instrument environmental 
considerations. SOURCE: Reference 7, Reqs 12-05 and 12-11. 

FNR31: The ICC will define the MODIS instrument schedule within the resources and 
guidelines provided by the EMOC. SOURCE: Reference 2 (ICC Facility) and Reference 10, 

p. 6. 


3.2.1.3 Resource Requirement Generation 

FNR32: The ICC shall receive science plans and resource allocations from the EMOC. 
SOURCE: Reference 3, pp. 5-16 and Reference 10, p. 6. 

FNR33: The ICC will simulate MODIS functional subsystems, including power, thermal, 
and tape recorder resources in determining scheduling resource requirements. SOURCE: 
Reference 7, Req 12-07 and from Reference 5, Req. 306. 

3.2. 1.4 Schedule Request Generation 

FNR34: The ICC shall plan and generate instrument operation sequences needed to 
satisfy the EMOC integrated mission schedule. SOURCE: Reference 2 (ICC Facility). 

FNR35: The ICC shall provide planning inputs to the EMOC. SOURCE: Reference 3 
(2.3.2). 

3. 2.1. 5 Command Sequence Generation 

FNR36: The iterated scheduling of MODIS operations shall be automated and shall result 
in an automated command sequence in an instrument executable format. Such commands shall 
be released to the EMOC for transmittal to the platform. An image of these commands shall 
be retained in the ICC for use by the Control and Monitor function. SOURCE: Reference 18, 
ICC Context Diagram and DFD’s 2.1 and 2.2. 

3.2. 1.6 Reference Monitoring Profile Generation 

FNR37: The ICC’s automated scheduling process shall result in a time-ordered image of 
the expected MODIS state and the expected values of instrumented telemetry. These expected 
values shall correspond exactly to the projected schedule of MODIS operations and shall, along 
with the image of commands, be made available to a Control and Monitor file and to the 
EMOC. SOURCE: Reference 18, ICC Context Diagram and DFD’s 2.1 and 2.2. 

3.2.1.7 Mission Planning Information 

FNR38: The ICC’s automated scheduler shall retain various mission planning data (to be 
specified) in the on-line ICC date base and shall be distributed to other MIDACS elements for 
use in their functional planning (e.g., CDHF discipline data production). SOURCE: Reference 
18, ICC Context Diagram and DFD 2.1. 
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3.2.2 Instrument Control and Monitor 


[See Data Flow Diagram 2.2: Control and Monitor Instrument] 

FNR39: The ICC shall use TDRS for normal command and telemetry operations. In the 
event of a contingency that prevents the use of TDRS, they shall use the Command and Data 
Acquisition (CDA) stations. Use of the CDA stations shall be scheduled and coordinated with 
NOAA via the EMOC. SOURCE: Reference 2 (ICC Facility), Reference 3, p. 5-28. 

FNR40: The ICC shall support the training of the MODIS instrument operations team. 
SOURCE: Reference 2 (ICC Facility). 

FNR41: The ICC shall support simultaneous EOS on-orbit operations and EOS servicing 
mission tests and simulations. SOURCE: Reference 2 (ICC Facility). 

3. 2.2.1 Instrument State-of -Health Monitoring 

FNR42: The ICC/IST shall provide the MODIS Instrument Scientist and/or his designated 
representatives the facilities to monitor the MODIS instrument performance by making 
available all the science instrument data in real time. SOURCE: Reference 19. 

FNR43: Facilities for real-time MODIS instrument monitoring shall include two interac- 
tive workstations; one each for the MODIS-N and MODIS-T instruments. SOURCE: Reference 
19 . 


FNR44: The scientist monitoring the real-time MODIS data shall be able to select, 
randomly or systematically, any four MODIS channels for simultaneous analysis for MODIS-N 
and for MODIS-T (a total of eight channels). SOURCE: Reference 19. 

FNR45: Upon selection, data from the designated channels shall begin to build 2000 km 
x 2000 km scenes in the workstations’ memory without delay. Once built, the scenes shall be 
continuously refreshed. SOURCE: Reference 19. 

FNR46: The DHC shall supply to the ICC, and the ICC shall be designed to accept, the 
entire MODIS instrument data stream in either real-time or priority-playback mode. SOURCE: 
Derived from FNR44 and FNR45). 

FNR47: Each workstation shall have sufficient internal RAM to store and manipulate the 
four scenes simultaneously (2,048 x 2,048 x 4 x 2 bytes) — > more than 34 megabytes), as well 
as 200 megabytes of on-line storage, TBD off-line storage, and TBD hardcopy output devices. 
SOURCE: Reference 19. 

FNR48: Each workstation shall be capable of performing TBD analysis of the data. 
SOURCE: Reference 19. 

FNR49: The workstations shall be capable of simultaneously performing both the display 
and analysis functions. SOURCE: Reference 19. 

FNR50: MODIS team members and support personnel shall have the capability to recon- 
figure observational sequences when malfunctions or special events occur. SOURCE: Refer- 
ence 2 (ICC Facility). 
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DFD 2.2 Control and Monitor Instrument 




FNR51: The ICC shall be capable of securing the MODIS instrument in the event of a 
problem that could endanger the instrument, other instruments, or the platform. SOURCE: 
Reference 2 (ICC Facility). 

FNR52: The ICC shall generate real-time commands (i.e., ones that are sent directly to 
instrument via the EMOC without buffering or delay) in reaction to an anomaly that requires 
the instrument to be reconfigured. SOURCE: Reference 2 (ICC Facility). 

FNR53: The ICC shall verify the receipt and correct execution of commands by the 
instrument for both real-time and stored commands. The ICC shall take appropriate action if 
notified that the command was not delivered. SOURCE: Reference 2 (ICC Facility). 

FNR54: The ICC shall have a real-time and playback telemetry data processing system to 
monitor MODIS instrument status and to confirm responses to commands. SOURCE: Refer- 
ence 2 (ICC Facility), Reference 3, p. 5-33. 

FNR55: The ICC shall monitor the MODIS instrument telemetry data. This includes limit 
checks and configuration checks. Alarms will be generated in the event a discrepancy is 
detected. SOURCE: Reference 2 (ICC Facility). 

FNR56: Ancillary data and data quality information shall be monitored in the ICC in the 
same manner as instrument telemetry data parameters. SOURCE: Reference 2 (ICC Facility). 

FNR57: The ICC shall receive MODIS science data for quick-look evaluation if required 
to operate the MODIS instrument or to support the operation (e.g., support of field site 
operation). SOURCE: Reference 2 (ICC Facility). 

FNR58: The ICC shall be capable of processing playback engineering data in packets 
whose order may be backwards. SOURCE: Reference 2 (ICC Facility). 

FNR59: The ICC shall be capable of accepting real-time and playback data simultane- 
ously. SOURCE: Reference 2 (ICC Facility). 

FNR60: The ICC shall receive packetized MODIS instrument engineering and ancillary 
data from the DHC. SOURCE: Reference 2 (DHC Facility, ICC Facility). 

FNR61: The ICC shall support a quick-look capability of selected data in near-real-time 
to support on-going data monitoring. SOURCE: Reference 11, p. 7. 

FNR62: Selected portions of the MODIS science data shall be forwarded to the ICC for 
evaluation. SOURCE: Reference 1, p. 7. 

FNR63: The ICC shall monitor the health and safety of the MODIS instrument. 

SOURCE: Reference 3 (derived from 2.3.2). 

FNR64: If problems occur, the ICC shall have the capability to trace the data flow back 
through the processing system to the instrument, aiding in the isolation and correction of 
these problems. SOURCE: Reference 6, p. 45. 

3.2.2.2 Engineering Trend Analysis 

FNR65: The ICC shall perform engineering trend analysis using MODIS and platform 
engineering data. SOURCE: Reference 2 (ICC Facility). 
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FNR66: MODIS instrument parameters should be monitored by examining its performance 
statistically. SOURCE: Reference 6, p. 45. 

FNR67: The historical ICC data shall be archived in the event further analysis is 
required. SOURCE: Reference 3, p. 5-17 and Reference 8, p. 5-12. 

FNR68: The ICC shall produce and maintain a MODIS instrument operations history 
which will include all commands, instrument status, and significant reconfigurations through 
the lifetime of the instrument. SOURCE: Reference 2 (ICC Facility); Reference 3, pp. 5-17; 
and Reference 5 (Req. 272). 

3.2.2.3 Command Processing 

FNR69: All command requests issued by the ICC to the EMOC shall consist of two parts: 
(1) the actual command load to be executed by the instrument; and (2) a description of what 
this command will do: power/thermal/tape recorder impacts, instrument mode, on/off times, 
data routes, movement/vibration. SOURCE: Reference 2 (ICC Facility) and Reference 3 
(2.3.1). 

FNR70: The ICC will receive command and observation requests from the MODIS 1ST. 
SOURCE: Reference 3, pp. 5-17 and Reference 10, p. 7. 

FNR71: The ICC shall verify the emergency command request from the authorized 
MODIS team member or EMOC. SOURCE: Reference 12, p. 10. 

FNR72: The ICC shall generate stored commands to execute the schedule. SOURCE: 
Reference 2 (ICC Facility). 

FNR73: The ICC shall provide a new command sequence in response to a schedule 
change directed by the team leader of the MODIS instrument. SOURCE: Reference 2 (ICC 
Facility). 

FNR74: The ICC shall validate the requested command load prior to sending it to the 
EMOC. SOURCE: Reference 3 (2.3.1). 

FNR75: The ICC will check the loads to insure that no MODIS instrument constraints 
are violated, and that the operation does not exceed the resources allocated to it in the 
schedule. SOURCE: Reference 10, p. 6. 

FNR76: The ICC shall store command loads necessary for MODIS instrument operation 
implementation. SOURCE: Reference 3, p. 5-16. 

FNR77: The ICC shall modify the command loads in response to the identification of an 
approved target of opportunity. SOURCE: Reference 2 (ICC Facility). 

3.2.2.4 Displays and Status Reports 

FNR78: The ICC shall monitor the MODIS instruments’ operation by processing and 
displaying MODIS instrument engineering data and platform ancillary data. SOURCE: 
Reference 2 (ICC) and Reference 10, p. 6. 

FNR79: The MODIS instrument team members shall be able to monitor MODIS instrument 
data in near-real-time for quality assurance, error detection, and malfunction assessment. 
SOURCE: Reference 2 (ICC Facility). 
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FNR80: The ICC shall generate and forward to EMOC for distribution messages on the 
status of MODIS that are required in other control centers. SOURCE: Reference 2 (ICC 
Facility). 

FNR81: The ICC will generate status data for any other control center that requires it. 
SOURCE: Reference 10, p.7. 

FNR82: The ICC shall provide data quality reports to the 1ST giving the status of the 
various onboard calibration sources as well as instrument response to the sources. These 
status reports would include the following parameters: 

1. Currents and voltages supplied to sources 

2. Temperature of sources 

3. Output of special sensor to monitor sources 

4. MODIS instrument response 
SOURCE: B. Markham. 

3.3 TEAM MEMBER COMPUTING FACILITY (TMCF) 

[See Data Flow Diagram 3.0: TMCF Functional Data Flows] 

3.3.1 Develop and Maintain Science/Calibration Algorithms 

[See Data Flow Diagram 3.1: Develop and Maintain Science/Calibration Algorithms] 

FNR83: Team Members shall be responsible for the development and maintenance of the 
algorithms for the production of data sets and for the development of instrument calibration 
algorithms and coefficients. SOURCE: Reference 3, pp. 2-24, 5-8. 

FNR84: The TMCF shall be composed of project provided computing resources at team 
member locations to be used in the development and test of algorithms. SOURCE: Reference 
3, pp. 2-24, 5-13. 


FNR85: The TMCF shall participate in the calibration of the MODIS instrument and 
incorporate calibration parameters in the data reduction procedure. SOURCE: Reference 3, p. 
5-8. 


FNR86: A continuing program of algorithm verification and development in the TMCF 
must be maintained after launch. SOURCE: Reference 17, p. 50. 

FNR87: A history of algorithm performance shall be maintained and accessible via the 
archives. SOURCE: Reference 6, Req. 93. 

FNR88: The TMCF shall inspect raw Level-0 data during the pre-launch testing phase of 
MODIS-N and MODIS-T, and shall provide the results of these tests shall be provided to the 
DADS. SOURCE: Reference B. Markham. 

3.3.1. 1 Develop Algorithms 

FNR89: The TMCF shall produce preliminary algorithms as part of the development of 
algorithms. SOURCE: Reference 18. 


28 



User-Processing-Request-Responses 



29 


DFD 3.0 TMCF Functional Data Flows 
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DFD 3.1 Develop and Maintain Science/Calibration Algorithms 



FNR90: The TMCF will use validation/verification study results and the Science Manage- 
ment Plan to develop algorithms. SOURCE: Reference 18. 

3.3.1.2 Test and Modify Algorithms 

FNR91: The TMCF shall accept correlative data, selected data products, archive data 
products, preliminary algorithms, and DQA reports as required for the testing and modification 
of algorithms. SOURCE: Reference 18. 

FNR92: The TMCF shall generate data processing requests, data product requests, and 
observation requests as required for the testing and modification of algorithms. SOURCE: 
Reference 18. 

FNR93: The TMCF shall produce revised algorithms as part of the testing and modifica- 
tion of algorithms. SOURCE: Reference 18. 

3.3.1.3 Implement and Certify Algorithms 

FNR94: The TMCF shall provide a temporary storage of algorithms used in the analysis of 
the data. SOURCE: NEW1. 

FNR95: The TMCF shall certify revised processing algorithms prior to their implementa- 
tion at the CDHF. SOURCE: Reference 18. 

FNR96: The TMCF shall provide processing algorithms, planning input, and algorithm 
release announcements as part of the implementation and certification of algorithms. Refer- 
ence 18. 

3.3.2 Verify/Validation Data 

[See Data Flow Diagram 3.2: Verify/Validate Data] 

FNR97: Communications capabilities shall be embedded into the data system so as to 
enable the delivery of near-real-time scene data to the investigators at the site of the 
experiments (within the specified timeliness requirements). SOURCE: Reference 19. 

FNR98: Computing resources shall be made available to the investigators at the site of 
the experiment (perhaps as portions of the distributed TMCF) to enable in-situ analysis of the 
MODIS data products. SOURCE: Reference 19. 

FNR99: The TMCF shall be project provided computing resources at team member 
locations to be used in data investigations and the validation of data. SOURCE: Reference 3, 
pp. 2-24, 5-13. 


FNR100: During the MODIS mission lifetime, the calibration of the instrument shall be 
maintained by the Calibration Support Team using TMCF with specific consideration of the 
absolute radiometric accuracy, absolute radiometric accuracy of polarization measurements, 
maximum allowable root-mean-square (rms) noise, detector to detector uniformity, spectral 
band to spectral band radiometric accuracy and long-term stability. SOURCE: Reference 14. 

FNR101: Prior to launch the Calibration Support Team using the TMCF shall assure that 
the calibration of the MODIS instrument meets the Science Team specifications such as 
spectral coverage, spectral band separation, polarization sensitivity, Stokes parameter deriva- 
tion in polarization studies, instrument field of view, focal plane configuration, system 
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DFD 3.2 Verify/Validate Data 



modulation transfer function, dynamic range, sensitivity, and quantization, linearity, radio- 
metric accuracy, and onboard source characterization. SOURCE: Reference 14. 

FNR102: The Calibration Support Team shall assure that the calibration is accurate to 
within two percent and stable over time. SOURCE: Reference 14. 

FNR103: Data taken by the onboard radiometric and spectral calibration systems for 
MODIS shall be used to maintain the calibration, such as 1) an onboard spectral response 
calibrator, to monitor sensor spectral response changes, 2) uniform, stable and known irradi- 
ance sources for all sensors passing through the entire optical system, and 3) inherently stable 
sources and/or use of a separate system to monitor source stability. SOURCE: Reference 14. 

FNR104: The onboard calibration sequence shall include calibration of the sensor elec- 
tronics and Calibration Support Team shall assure these calibrations are maintained. SOURCE: 
Reference 14. 

3.3.2.1 Receive and Catalog Data Inputs 

FNR105: The TMCF shall receive and catalog archive data products from the DADS 
required for the validation and verification of data. SOURCE: Reference 18. 

FNR106: The TMCF shall receive and catalog correlative data products from the DADS 
required for the validation and verification of data. SOURCE: Reference 18. 

FNR107: The TMCF shall receive and catalog selected data products from the CDHF 
required for the validation and verification of data. SOURCE: Reference 18. 

FNR108: The TMCF shall receive and catalog DQA reports from the CDHF as required 
for the validation and verification of data. SOURCE: Reference 18. 

3.3.2.2 Produce Special Data Products 

FNR109: The production, short-term storage, and dissemination of scientifically useful 
data sets shall be performed by the TMCF. SOURCE: Reference 3, p. 5-9. 

FNR110: Higher level data sets shall be tagged with an identifier for the algorithm used 
to generate the data from lower level data. Identifiers shall also be retained for the lower 
level algorithms, calibration constants, and engineering data that were used to generate the 
lower level data on which the higher level processing is based. SOURCE: Reference 2, Ch. 
VI. 


FNR111: TMCF investigators must return results of their analyses to the system. Addi- 
tional processing of the data, resulting from the investigation, shall be required to provide: 1) 
a catalog entry containing descriptions of the data sources, data properties, analysis methods, 
and attributes (e.g, location, time, wavelength), 2) a standard format to allow access from 
EosDIS software and processing by EosDIS archival software, 3) documentation of data set 
contents, processing algorithms, and instrument characteristics, and 4) an evaluation of the 
results, including error analyses and validation tests, as well as a relevant library. SOURCE: 
Reference 6, p. 27. 

FNR112: The TMCF shall function according to the science management plan in the 
production of special data products. SOURCE: Reference 18. 
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FNR113: The TMCF shall use received data, processing algorithms, and 
validation/verification study results in the production of special data products. SOURCE: 
Reference 18. 

FNR114: The TMCF shall generate data processing requests, data product requests, and 
observation requests required for the production of special data products. SOURCE: Refer- 
ence 18. 

FNR115: The TMCF shall provide data product archive release authorizations. SOURCE: 
Reference 18. 

FNR1K5: The TMCF shall produce preliminary specialized data products prior to the 
production of special data products. SOURCE: Reference 18. 

FNR117: The TMCF shall provide planning input concerning the production of special 
data products to the science management plan. SOURCE: Reference 18. 

3.3.2.3 Perform Statistical Studies and Modeling 

FNR118: The TMCF shall participate in intercomparisons of calibrated instruments such as 
a comparison of MODIS to HIRIS. SOURCE: Reference 15. 

FNR119: The TMCF shall generate data product requests and data processing requests 
when performing statistical studies and modeling. SOURCE: Reference 18. 

FNR120: The TMCF shall receive archive data products, correlative data products, and 
selected data products, and DQA reports when performing statistical studies and modeling. 
SOURCE: Reference 18. 

FNR121: The TMCF shall produce specialized data products, validation/verification study 
results, and planning input when performing statistical studies and modeling. SOURCE: 
Reference 18. 

3.3.3 Plan and Coordinate 

[See Data Flow Diagram 3.3: Plan and Coordinate Support] 

FNR122: The Team Leader shall develop a plan in conjunction with the team members 
which describes the data delivery obligations of the Team to the EosDIS. SOURCE: Refer- 
ence 3, p. 5-9. 

3.3.3.1 Receive Requests and Catalog 

FNR123: The TMCF shall receive and catalog team member and user processing requests, 
data product requests, and observation requests, as part of planning and coordination. 

SOURCE: Reference 18. 

FNR124: The TMCF shall produce received requests as part of planning and coordination. 
Reference 18. 

3.3.3.2 Sort and Set Priority of Requests 

FNR125: The TMCF shall sort and prioritize all received requests as part of planning 
and coordination. SOURCE: Reference 18. 
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DFD 3.3 Plan and Coordinate Support 


FNR126: The TMCF shall use the science management plan as a guide for the sorting 
and prioritization of requests. SOURCE: Reference 18. 

FNR127: The TMCF shall provide team members and MIDACS with priority ranked 
requests as part of sorting and prioritization of requests. SOURCE Reference 18. 

3.3.3.3 Develop Science Management Plan 

FNR128: The Team Leader shall develop a Science Management Plan (including the 
assignments and responsibilities of each team member), which shall be updated at least once 
per year. SOURCE: Reference 3, p. 5-7. 

FNR129: The team leader shall consider planning input for the development of the 
science management plan from both team members and outside sources. SOURCE: Reference 
18. 


FNR130: The team leader shall accept data product release announcements and algorithm 
release announcements as input for the development of the science management plan. 

SOURCE: Reference 18. 

3.3.3.4 Send Requests 

FNR131: The TMCF shall distribute priority ranked team member and user request 
responses to the IMC as part of planning and coordination. SOURCE: Reference 18. 

FNR132: The TMCF shall distribute priority ranked TMCF processing requests to the 
CDHF as part of planning and coordination. SOURCE: Reference 18. 

FNR133: The TMCF shall distribute priority ranked TMCF observation requests to the 
1ST as part of planning and coordination. SOURCE: Reference 18. 

FNR134: The TMCF shall distribute priority rankefd archive data requests to the DADS 
as part of planning and coordination. SOURCE: Reference 18. 

FNR135: The TMCF shall distribute priority ranked correlative data requests to the non- 
EOS data sources as part of planning and coordination. SOURCE: Reference 18. 

3.4 CENTRAL DATA HANDLING FACILITY (CDHF) 

[See Data Flow Diagram 4.0: CDHF Functional Data Flows] 

3.4.1 Receive DHC Data 

[See Data Flow Diagram 4.1: Receive Data] 

3.4. 1.1 Ingest Data 

FNR136: The CDHF shall accept MODIS Level-0 data from the DHC. SOURCE: Refer- 
ence 3, pp. 2-8 and 5-29. 

FNR137: The CDHF shall receive Level-0 data and ancillary data from the DHC. The 
Level-0 data shall be in a form that is sequenced by time, by focal plane, by along-track dis- 
tance, and by band configuration along the scan direction. Ancillary data shall have been 
checked, at the DHC, against high and low limits, and validated by comparisons 
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DFD 4.0 CDHF Functional Data Flows 



with orbit and attitude reference profiles. The Level-0 data shall have been transmission 
error corrected and redundancies removed. SOURCE: Reference 20 and Reference 3, pp. 2-8 
and 5-29. 

FNR138: The Level-0 data shall contain: 

a. Instrument science data in the form of digital counts 

b. Calibration target data taken at most once per scan 

c. Instrument engineering data 

FNR139: The ancillary data shall include: 

a. Time and spacecraft ephemeris 

b. Spacecraft attitude and/or instrument attitude 

c. Platform engineering data 

d. Other ancillary data 

FNR140: The CDHF shall accept MODIS Level-0 data, most of which are TBD bits in 
length and packed. 

3.4.1.2 Perform Acceptance Checking 

FNR141: The CDHF shall perform TBD acceptance checking of Level-0 data and request 
any necessary retransmission of data from the DHC. SOURCE: Reference 20. 

3.4.1.3 Reformat Data and Append Header 

FNR142: The CDHF shall perform any necessary reformatting of received Level-0 data 
and will append standard headers. SOURCE: Reference 20. 

3.4.2 Produce Data Products 

[See Data Flow Diagram 4.2: Produce Data Products] 

FNR143: The basic Levels-2, -3, and -4 data product time spans shall be TBD. 

FNR144: The spatial and temporal resolution of scientific parameters contained in the 
Levels-2, -3, and -4 data products shall be TBD. 

FNR145: The Levels-3 and -4 data product formats shall be TBD. 

FNR146: The Levels-1, -2, -3, and -4 data products shall have appended to the various 
levels of data organization (from the basic product length to the lowest level of segmentation 
or gridding), TBD-appended information from the lower level input data, geophysical parameter 
identification(s), geophysical parameter algorithm version identification(s), gridding description 
and statistics for Level-3, correlative data information for Level-4, geophysical or applications 
model identification for Level-4, data quality assessment information, processing date, and 
version number. 

FNR147: The word sizes for Levels-2, -3, and -4 data products are TBD. 

FNR148: TBD data compression shall be applied to TBD Levels-2, -3, and -4 products. 
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DFD 4.2 Produce Data Products 


FNR149: Higher level data shall be tagged with an identifier for the algorithm used to 
generate the data from lower level data. Identifiers shall also be retained for the lower level 
algorithms, calibration constants, and engineering data that were used to generate the lower 
level data on which the higher level processing is based. SOURCE: Reference 20. 

FNR150: The Levels-1, -2, -3, and -4 processors shall each be capable of performing 
reprocessing, special requests, near-real-time, and backlog processing, in addition to the 
standard processing of playback data. SOURCE: Reference 20. 

FNR151: Levels-1, -2, -3, and -4 products shall contain all of the information necessary 
for the creation of catalogs and inventories of Levels-1, -2, -3, and -4 data, and this informa- 
tion should be passed on to the next level of processing. SOURCE: Reference 20. 

FNR152: The time span of the basic Level-1 product is TBD, but may be multi-day, 
daily, orbital, or a fraction of a day, etc. SOURCE: Reference 20. 

FNR153: The Level-1 processor shall organize the science data into logical data records 
that are TBD. The natural blocking of the MODIS data is by observation swath (64 km x 1780 
km for MODIS-T and 8 km x 1780 km for MODIS-N). Note that calibration reference data are 
taken, at most, once per swath or scan. The requirement of putting one full swath into the 
memory of a processor may be too stringent for many users. It is anticipated that a strategy 
shall be developed to break swaths into smaller pieces (segmentation). Any segmentation 
strategy should have the following characteristics: 

a. Each segment should be preceded by a segment description header. 

b. Each segment should be made as complete as possible in terms of Earth location and 
calibration of the pixels. 

c. Segmentation should promote ease of the next level of processing. 

SOURCE: Reference 20. 

FNR154: The organization of the Levels-IA and -IB data within a swath shall be spectral 
channel sequential (i.e., sequential pixels in all scan lines within a swath shall be from the 
same channel). SOURCE: Reference 20. 

FNR155: The Levels-IA and -IB data products shall have appended to the various levels 
of data organization (from the basic product length to the lowest level of segmentation) 
subsets of the following ancillary data (the resolutions in time and space are TBD): 

a. MODIS-N/MODIS-T sensor identification 

b. Product sequence number/version number 

c. Processing date 

d. Calibration algorithm identification number/version number 

e. Product start and stop times 

f. Orbit number(s) 

g. Geographical boundaries of the product 

h. Channel identification 

i. Data quality flags 

j. Calibration quality flags 

k. Housekeeping data 

l. Engineering data 

m. Land/ocean flags 

n. Measure of cloudiness 
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o. Instrument tilt information (MODIS-T) 

p. Scan number(s) 

q. Attitude information 

r. Platform ephemeris 

s. Time code 

t. Solar and satellite zenith angle information 

u. GPS time correction 

v. Platform structure telemetry 

w. Calibration coefficients (Level-IB) 

SOURCE: Reference 20. 

FNR156: There shall be separate Levels-IA and -IB calibration data products which shall 
consist of data taken during calibration modes (i.e., when the sensor views the diffuser plate, 
calibration blackbodies, etc.). SOURCE: Reference 20. 

FNR157: The data quality software shall d' tect and record significant instrument 
performance changes. SOURCE: Reference 6, page 25. 

FNR158: The CDHF shall assess the quality of science data in near-real-time for 
selected samples of data. SOURCE: Reference 5, p. B-13. 

FNR159: The CDHF shall produce TBD browse images. SOURCE: Reference 20. 

FNR160: The CDHF shall support image resampling and enhancement of calibrated image 
data sets. SOURCE: Reference 7, p. 5-28. 

FNR161: The CDHF shall support data reduction, grid overlay, standard projection data 
set production, and data set merger. SOURCE: Reference 6, page vii. 

3.4.2.1 Process Level-1 A 

FNR162: Until reversibility of the calibration process is demonstrated, it is assumed that 
all of the Level-0 data shall be processed to Levels-IA and -IB, and that both Levels-IA and 
-IB products shall be archived. SOURCE: Reference 20. 

FNR163: There shall be separate MODIS-N and MODIS-T Level- 1 A products. There 
probably shall be different calibration requirements and algorithms for different spectral 
channels and for different higher level processing (e.g., for land, ocean, and atmospheric 
products). Therefore, there shall probably be several Level-IA products some of which arc 
combinations of MODIS-T and MODIS-N channels. SOURCE: Reference 20. 

FNR164: Level-1 A data shall be Level-0 data which are reformatted reversibly, with 
Earth location, solar and instrument zenith angle, calibration data, and other ancillary and 
instrument engineering data appended. SOURCE: Reference 20. 

FNR165: The inputs to the Level-1 processor shall include: 

a. Level-0 data 

b. Spacecraft ephemeris data and attitude data from backup systems 

c. Other ancillary data (e.g., CIA world map) 

SOURCE: Reference 19. 

FNR166: The word size for the Level- 1 data products is TBD. 
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FNR167: The data compression format on-board the POP-1 or on the ground is TBD. 

FNR168: The Level-IA data product shall contain the Level-0 counts of the sensor and 
the ancillary and instrument engineering data. 

FNR169: All algorithm identifiers and constants necessary to recover Level-0 data from 
Level- 1 A products shall be appended to the Level- 1 A data. SOURCE: Reference 5, 
p. A-7. 


FNR170: The CDHF shall strip out embedded calibration information from MODIS Level-0 
data for use in the data processing. SOURCE: Reference B. Markham. 

3.4.2.2 Process Level-IB 

FNR171: The CDHF shall process calibration scenes to Level-1 B. SOURCE: Reference B. 
Markham. 

FNR172: There shall be separate MODIS-N and MODIS-T Level-IB products and certain 
other standard Level-IB products which may consist of combinations of selected MODIS-N and 
MODIS-T channels. For example, there may be different calibration algorithms and, therefore, 
separate IB products for land, ocean, and atmospheric processing. SOURCE: Reference 20. 

FNR173: Level-IB data shall be Level-1 A data to which the radiometric calibration 
algorithms have been applied, perhaps irreversibly, to produce values of the instrument 
measurements (e.g., radiances or irradiances), and to which, the Earth location, and zenith 
angle algorithms have been applied. SOURCE: Reference 20. 

FNR174: The Level-IB data product shall be, to the greatest extent possible, identical in 
format to that of Level-IA; however, the radiometric calibration shall be applied to the sensor 
units, and Earth location computations shall be applied at the anchor points. SOURCE: 
Reference 20. 

FNR175: The CDHF shall process all data at least to Level-1 B. Processing beyond 
Level-1 B shall be handled on a request basis. SOURCE: Reference 5, p. A-7. 

3.4.2.3 Process Level-2 

FNR176: The Level-2 processor shall receive Level-IB data and any ancillary data neces- 
sary for the Level-2 processing step. 

FNR177: The Level-2 product shall contain geophysical parameters derived from the 
Level-1 B data by the application of geophysical parameters derived from the Level- IB data by 
the application of geophysical parameter algorithms. 

FNR178: The Level-2 data product format shall be similar to that of the IB data (i.c., 
orbital swaths of geophysical parameter values plus appended information. 

FNR179: A basic set of derived properties is to be routinely computed for all appro- 
priate incoming data. Candidate items are: 

1. Terrestrial Leaf Area Index 

2. Ocean Chlorophyll Pigment 

3. Terrestrial Surface Temperature 

4. Sea Surface Temperature 
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5. Aerosol Optical Depth (over oceans) 

6. Chlorophyll Fluorescence 

7,8. Additional Terrestrial Vegetation Indices 

9. Bioluminescence 

10. Ocean Cyanobacteria Index 

11. Terrestrial Aerosol 
12-15. Atmospheric Properties 

16. Oceanic Particulate Calcium Carbonate Concentration 

17. Cloud Top Pressure 

18. Outgoing Longwave Radiation 

19. Longwave Cloud Radiative Forcing 

20. Cloud Fraction 

21. Precipitation 

22. Ground Temperature 

23. Atmospheric Humidity Profile 

24. Atmospheric Ozone Profile 
SOURCE: Reference 8 (Ch. VI), J. Susskind. 

FNR180: The CDHF shall compile statistical information for each unit of Level-2 data 
processed. SOURCE: Reference 6, p. 6. 

3.4.2.4 Process Level-3 

FNR181: The Level-3 processor shall receive Levels-1 and -2 data and any ancillary data 
necessary for the Level-3 processing step. SOURCE: Reference 20. 

FNR182: The Level-3 data product shall contain Earth-gridded geophysical parameter 
data including radiances, etc., from Level-I averaged or composited in time and in space. 
SOURCE: Reference 20. 

3.4.2.5 Process Level-4 

FNR183: The Level-4 processor shall receive Levels-1, -2, and -3 data and any ancillary 
or correlative data necessary for the Level-4 processing step. 

FNR184: The Level-4 product shall contain TBD analyses of the lower levels of MODIS 
data products. 

3.4.3 Manage Processing and Handle Data 

[See Data Flow Diagram 4.3: Manage Processing and Handle Data] 

3.4.3. 1 Receive Data 

FNR185: The CDHF shall receive any archive data or processing algorithms necessary for 
Levels-1 through -4 processing. SOURCE: Reference 20. 

FNR186: The CDHF shall acquire calibration coefficients and algorithms from the TMCF 
for use in the routine processing of Level-IA data to Level-IB. SOURCE: Reference J. 

Barker. 

FNR187: The CDHF shall acquire special calibration coefficients and algorithms from the 
TMCF to test new approaches and to provide calibrated Level-IB data to the TMCF. SOURCE: 
Reference J. Barker. 
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CDHF DFD 4.3 Manage Processing & Handle Data 


3.4.3.2 Catalog and Store Data 

FNR188: The CDHF shall temporarily catalog and store data for routine processing, 
special processing, or reprocessing. SOURCE: Reference 3, p. 6-16; Reference 20. 

FNR189: The CDHF shall compute parameters that are needed to support the indexing 
and cataloging of data. SOURCE: Reference 20. 

3.4.3.3 Distribute Data 

FNR190: The CDHF shall transmit MODIS products and DQA reports to the DADS for 
archiving. SOURCE: Reference 20. 

FNR191: The CDHF shall provide subsets of standard, near-real-time, or specialized data 
to the TMCF upon request. SOURCE: Reference 18. 

FNR191: The CDHF shall transmit selected subsets of MODIS science data to the ICC 
for monitoring of instrument performance. SOURCE: Reference 18. 

FNR192: The CDHF shall support the archiving of processing algorithm identifiers and 
calibration constants. SOURCE: Reference 5, p. A-6 and Reference 7, p. 5-29. 

3. 4. 3. 4 Control Processing 

FNR193: The CDHF shall perform job accounting functions daily and send reports to the 
IMC. SOURCE: Reference 7, p. 5-29. 

FNR194: The CDHF shall accomodate new algorithms, access lower level data required 
for reprocessing, reprocess the data and update the archives with the resulting, improved data. 
SOURCE: Reference 6, page 7. 

FNR195: The CDHF shall be capable of processing and reprocessing science data when 
requested to do so by the MODIS team. SOURCE: Reference 3, pp. 2-22, 5-30, 6-12 and 
Reference 5, p. A-6. 

FNR196: Some near-real-time processing shall be required for operational purposes. 
SOURCE: Reference 6, page vii. 

FNR197: The CDHF shall provide near-real-time processing in support of field experi- 
ments, geophysical event monitoring, and scientific quick-look analysis. SOURCE: Reference 5, 
p. A-8 and Reference 6, p. 5. 

FNR198: The CDHF shall support the generation of data quality assessments. SOURCE: 
Reference 6, pp. 6 and 9. 

FNR199: The CDHF shall provide interactive image processing and display to users 
requiring real-time or quick-look information. SOURCE: Reference 5, p. A-6. 

3.5 DATA ARCHIVE AND DISTRIBUTION SYSTEM (DADS) 

[See Data Flow Diagram 5.0: DADS Functional Data Flows] 
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3.5.1 Receive Data 


[See Data Flow Diagram 5.1: Receive Data] 

3.5. 1.1 Ingest Data 

FNR200: All sources of calibration information, procedures, and results must be identi- 
fied and placed in the archival documentation. SOURCE: Reference 6, req #88. 

FNR201: The DADS shall be able to ingest data sets as they become available, including 
in-situ data sets. This includes large data sets of the 1990’s. SOURCE: Reference 5 (Req. 

No. 0101). 

FNR202: Self-documenting software shall be required to create directory entries for 
newly acquired data. SOURCE: Reference 6, p. 46. 

FNR203: Data from both optical components (MODIS-N and MODIS-T) shall be consid- 
ered as a single data set. SOURCE: Reference 8, page vi. 

FNR204: The DADS shall accept data from the TMCF for archive. SOURCE: 

Reference 3. 

FNR205: The DADS shall receive specialized products, correlative data, and algorithms 
from the TMCF. SOURCE: Reference 3, pp. 2-23. 

FNR206: The DADS shall accept MODIS data from the CDHF for archive. SOURCE: 
Reference 3. 

FNR207: The DADS shall receive MODIS reprocessed data from the CDHF. SOURCE: 
Reference 5, pp. A-6. 

FNR208: The DADS shall provide access to archive data from other platforms, other 
remote sensors, and from in-situ sensors for processing and validation of data sets. SOURCE: 
Reference 5 (Req. No. 0057 and 0030). 

FNR209: The DADS shall provide for access to non-Eos data and model sources 
including: (1) directory of catalogs, (2) information on specific catalog access, (3) place data 
orders, (4) direct access, (5) direct order, and (6) real-time access. SOURCE: Reference 5 
(Req. No. 0007). 

FNR210: The DADS shall accept correlative and ground truth data from other sources. 
SOURCE: Reference 5 (Req no 248). 

3.5.1. 2 Perform Acceptance Checking 

FNR211: The DADS shall provide acceptance checking of all data ingested. SOURCE: 
Reference 6, p. 46. 

3.5.1.3 Process Headers 

FNR212: For each unit of processed data, a catalog record shall be generated, and shall 
include record start and stop times, and accountability of information to be maintained in 
catalogs. SOURCE: Reference 9, p. 3-10. 
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FNR213: Management software shall determine the source and contents of data sets, 
record what processing has been performed, where the data are stored, and form a cross 
reference list of data coverage, time, etc. This software shall prepare a catalog entry 
containing this information. Acquisition of non-Eos data sets for Eos purposes requires 
processing of these data to allow equivalent catalog entries to be made. SOURCE: Reference 
6, page 25. 

3.5.1.4 Organize Data 

FNR214: The DADS shall archive by grouping of products (e.g., science regional and 
global). SOURCE: Reference 8, pp. 44 and 46. 

FNR215: Although the data processing facility is responsible for seeing that all required 
data cataloging parameters are processed, the actual execution of a data classification scheme 
(parameter limits, etc.) is the responsibility of the DADS. The data discriminants available to 
the user shall include the algorithm identification appended during the high level processing. 
SOURCE: Reference 2 (Ch. VI) 

FNR216: In the DADS, data shall be arranged into stable, predictable units to allow for 
automated cataloging, and easy user access to large data volumes. SOURCE: Reference 5 
(Req. No. 0290). 

3.5.2 Manage Data 

[See Data Flow Diagram 5.2: Manage Data] 

3.5.2.1 Store Data 

FNR217: The DADS shall support an archive storage volume of TBD. 

SOURCE: Reference 5 (Reqs 318-328). 

FNR218: The DADS shall store Level-1 through Level-4 processed data and Level-0 data 
for which there is no Level-1 product reversible to Level-0. SOURCE: Reference 3, pp. 6-13. 

FNR219: The DADS shall store investigator-generated data products. SOURCE: Refe- 
rence 3, pp. 5-36. 

FNR220: The DADS facility shall temporarily store processed data sets for limited 
periods of time. SOURCE: Reference 3, p. 5-17, 5-33, and 5-34. 

FNR221: The DADS archive shall provide browse file archives composed of reduced 
resolution data sets processed at least to Level-2, having regional or global coverage, and 
providing rapid interactive responses. SOURCE: Reference 5 (Req. No. 0328). 

FNR222: The DADS shall store the following types of data: MODIS Data Products, 
Ancillary Data, Correlative Data, Specialized Data, Algorithms, Documentation, and Browse 
Data. SOURCE: Reference 3, pp. 5-17. 

FNR223: The DADS shall include documentation of calibration procedures and results, 
including approximations and uncertainties. Calibration standards shall be trackable to the 
National Bureau of Standards. SOURCE: Reference 5 (Req. No. 0209) and Reference 6, p. 47. 
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DFD 5.2 Manage Data 


FNR224: The DADS shall maintain an archive of calibration constants applied to the 
data. This archive shall be correlated with other data to enable reprocessing of old data 
using the same calibrations applied originally. SOURCE: Reference 5 (Req. No. 009). 

FNR225: The DADS shall support on-line storage of data. SOURCE: Reference 3, pp. 

6-13. 


FNR226: Data attributes (e.g., cloud type and cover, vegetation type and cover, snow 
cover, data quality) should be appended to an inventory record within the browse files. 
SOURCE: Reference 6, p. 47. 

FNR227: Attribute files should be expandable, enabling researcher-identified attributes to 
be added subsequently. SOURCE: Reference 6, p. 47. 

FNR228: The archives shall provide an on-line bibliography containing references to all 
published and unpublished literature delivered from the project and shall allow users attribute 
searches. SOURCE: Reference 5 (Req. No. 0239). 

FNR229: The archive shall provide off-line support of data subset selection by media 
volume only. SOURCE: Reference 5 (Req. No. 0263). 

FNR230: The DADS shall archive software used to process reduced volume data sets. 
SOURCE: Reference 7, p. 5-30. 

FNR231: The DADS shall provide product archiving of processed data to a permanent 
archive. SOURCE: Reference 3, p. 5-36. 

FNR232: The DADS shall purge data in temporary storage after the data have been 
placed in permanent archive. SOURCE: FNR188 and FNR189, and Reference 5 (Req. 0304). 

FNR233: The routine Level-3 products shall be archived permanently. SOURCE: Refer- 
ence 8, page 44. 

FNR234: Level-IB data, together with the cloud and land/ocean masks, shall be archived 
permanently. SOURCE: Reference 8, page 44. 

FNR235: The DADS shall maintain documentation that describes the data processing 
procedures. SOURCE: Reference 3 

FNR236: The DADS shall maintain a history of the calibration of the instruments used in 
the routine data processing, as supplied by the TMCF. Separate histories of each of the 
monitored instrument parameters shall be maintained. Each history can itself be considered as 
an auxiliary data product, such as: 

a. Gains and offsets with uncertainties 

b. Linearity checks 

c. Polarization sensitivity studies 

d. Spectral band to spectral band radiometric accuracy 

e. Electronics calibration 

f. On-board radiometric source output 

SOURCE: Reference 3, 5 (req.no. 0209) 
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FNR237: If more than one calibration history exists (e.g., if the data are reprocessed), 
then all calibration histories shall be archived by the DADS along with information about how 
it was used in the data processing. SOURCE: Reference 5 (req. no. 009); J. Barker. 

FNR238: The DADS shall maintain results of the prelaunch testing and calibration 
including raw data and processed results. SOURCE: Reference 5 (req. No. 0209); B. Markham. 

3.5.2.2 Manage Catalog 

FNR239: Browse files should be visually searchable via attributes and by expert system. 
SOURCE: Reference 6, p. 47. 

FNR240: The DADS shall provide a directory of information showing location, ownership, 
data type, data processing level, version, parameter, time, or any combination of these. 

SOURCE: Reference 6, p. 46. 

FNR241: The DADS shall provide a catalog of information showing project, platform, 
instrument, data processing level, version, parameter, time, geographic location, or any 
combination of the above. SOURCE: Reference 6, p. 46. 

FNR242: The DADS archives directory shall include information about earth sciences 
data considered relevant by EOS-sponsored researchers, including an inventory of relevant 
documents concerning the data and archives. SOURCE: Reference 5 (Req. No. 0330). 

FNR243: The DADS shall maintain and update the archive catalog and directory. 
SOURCES: Reference 6, pp. 46 and 47 and Reference 7, p. 5-23. 

FNR244: On-line browse capabilities may not be possible for many users; this shall 
necessitate publication of an image browse catalog. SOURCE: Reference 6, p. 47. 

FNR245: The MODIS data catalogs and directories shall accommodate data changes due 
to sorting, editing or labeling analysis, due to production of associated data, either inferred or 
correlated. SOURCE: Reference 5 (Req. No. 0243). 

' 4 > ■' • 

FNR246: The directory shall include information about supporting catalog access. 
SOURCE: Reference 6, p. 46. „ 

FNR247: The directory and catalog shall be electronically available. SOURCE: Refer- 
ence 6, p. 46. 

FNR248: The DADS shall periodically update the IMC catalog and directories. SOURCE: 
Reference 3, pp. 2-23 and 25. 

FNR249: The DADS shall maintain a variety of catalogs and directories on-line to 
accommodate ordering by date and time; instrument channel, resolution, and operating modes; 
environmental parameters; geophysical location; feature detection; data location; etc. SOURCE: 
Reference 3, p. 2-27. 

FNR250: The data catalog shall be accessible by project, platform, instrument, data 
processing level, versions, parameter, time, geographic location, or any combination of the 
above. SOURCE: Reference 6, page 46. 

FNR251: All processing software shall be preserved and documented, along with a report 
of design and testing rationale used by the software creator. This requirement also applies to 
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processing software used to locate the observations and calculate observational geometry 
parameters. SOURCE: Reference 6, page 12. 

FNR252: The multi-tiered network shall serve multiple uses ranging from simple catalog 
searches to distribution of the low-level satellite data for further processing. SOURCE: 
Reference 8, page 44. 

FNR253: Data quality and catalog software shall be able to detect and record instrumen- 
tation changes. SOURCE: Reference 6, page 25. 

3.5.2.3 Report Status 

FNR254: The DADS shall periodically provide performance summary archives to include 
data accounting summaries and other non-spatial data sets having no geographical dependence. 
SOURCE: Reference 5 (Req. No. 0217). 

FNR255: The DADS shall be automated to handle large data volumes effectively; 
recordkeeping and generation of summary reports should be added functions. Management 
software shall determine the source and contents of data sets, record what processing has 
been performed, where the data are stored, and form a cross reference list. The software 
shall prepare catalog entries. Any use of the data should also be monitored and recorded. 
SOURCE: Reference 9, p. 88-89. 

FNR256: The DADS shall generate status reports (i.e., define status of the system, data 
volume handled, data request backlog, etc.). SOURCE: Reference 7, p. 5-27. 

FNR257: The DADS shall perform job accounting functions daily and send reports to the 
IMC. SOURCE: Reference 7, p. 5-29. 

FNR258: The DADS shall provide accounting information for each product order such as 
catalog usage, archival loading, and resource usage. SOURCE derived from Reference 5, p. 

6-49 and Reference 7, p. 5-29. 

FNR259: The DADS shall monitor performance of the archive system. SOURCE: 
Reference 7, p. 5-26. 

3.5.3 Process User Requests 

[See Data Flow Diagram 5.3: Process User Requests] 

3.5.3.1 Receive User Request 

FNR260: The DADS shall provide users with the ability to order through the catalog 
subsystem. Orders may be handled manually. SOURCE: Reference 5 (Req. No. 0264). 

FNR261: The DADS shall verify and convert product queries to orders. SOURCE: 
Reference 6, p. 46. 

FNR262: The DADS shall provide users with browse capability of reduced volume data 
sets. These data sets shall be made available at several processing levels. 

SOURCE: Reference 3 
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DFD 5.3 Process User Requests 



FNR263: The DADS shall provide interactive image processing and display to users 
requiring real-time or quick-look information. Interactive image browse capability and 
interactive data processing shall also be provided. SOURCE: Reference 3 

FNR264: The DADS shall support exchange of heterogeneous data sets, not only among 
the different elements of EosDIS, but also with other systems both internal and external to 
NASA. SOURCE: Reference 6, page 18. 

FNR265: The DADS shall provide for interactive, electronic catalog and ordering 
functions with a minimum 9600 bps dial-up capability. SOURCE: Reference 5 (Req No 37). 

FNR266: The DADS shall support query of referenced data bases by other Eos elements. 
SOURCE: Reference 5 (Req. No. 0261). 

FNR267: The DADS shall be capable of retrieving and sending data sets to the CDHF for 
reprocessing in response to a data request. SOURCE: Reference 5, p. A6. 

3.5.3.2 Generate Order Status 

FNR268: The DADS shall generate status reports of the retrieval process for requested 
data and make these available to the requestor and/or the IMC. SOURCE: Reference 7, p. 5- 
26 and 29. 

3.5.3.3 Retrieve Data 

FNR269: The DADS shall be capable of locating one or more requested data sets or 
products by searching through its data structure of the data archive based on data parameters 
or product attributes specified in the request. SOURCE: Reference 12, p. 34. 

FNR270: Browse files should be accessible by time, geographic, location, or any combina- 
tion of these factors. SOURCE: Reference 6, p. 47. 

FNR271: The DADS shall follow a standard format structure for data interchange. 
SOURCE: Reference 6, page 14. 

3.5.4 Distribute Data 

[See Data Flow Diagram 5.4: Distribute Data] 

FNR272: The DADS shall provide for a spectrum of electronic delivery rates. SOURCE: 
Reference 6, p. 46. 

FNR273: High-density storage media (e.g., optical disk or tape) shall be used to distri- 
bute data in lieu of communication links. SOURCE: Reference 3, p. 5-39. 

3.5.4.1 Generate Direct Product 

FNR274: High-density storage media (e.g., optical disk or tape) shall be used to distri- 
bute data in lieu of communication links. SOURCE: Reference 3, p. 5-39. 

3.5.4.2 Transmit Data 

FNR275: The DADS shall distribute data sets to users on appropriate media or transmit 
data over a communications line. SOURCE: Reference 5 (Req. No. 0271). 
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DFD 5.4 Distribute Data 


FNR276: The DADS shall provide for a spectrum of electronic delivery rates. SOURCE: 
Reference 6, p. 46. 

3.6 ON-BOARD PROCESSING 

FNR277: To facilitate the analysis of real-time data, the MODIS data shall be packetized 
on board the platform by channel, detector, and scan line (1,292 pixels by 12 bits corresponds 
to 1,938 8-bit bytes). SOURCE: Reference 19. 

FNR278: The MODIS data shall be buffered on board the platform for a complete scan 
to permit the required packetization of the data. SOURCE: Reference 19. 

FNR279: On-board storage of 8 megabytes for MODIS-T (64 x 64 x 1,294 x 12/8) and 1.5 
megabytes for MODIS-N (752 x 1,294 x 12/8; 752 - 30 x 8 + 8 x 32 + 2 x 128) shall be 
required to provide on-board buffering capabilities. SOURCE: Reference 19. 

FNR280: Employ standards that require each data source (e.g., engineering subsystem, 
instrument) to encapsulate its data messages into source packets having globally interpretablc 
labels that define the source and destination, class of service, priorities and delivery condi- 
tions, and provide the information required for verification, validation, and accounting of data 
within the packet. SOURCE: Reference 6, page 16. 

FNR281: The on-board processing system of MODIS shall have information about the 
current and future positions of the spacecraft, the attitude of the spacecraft and the sensors, 
sun position, and surface illumination angles. Reference 8, page 43. 

FNR282: The on-board processing system of MODIS shall store a world map that identi- 
fies some essential characteristics of the earth in regions varying in size from approximately 
30 km x 30 km to 300 km x 300 km, depending on their location. Reference 8, page 43. 

4. PERFORMANCE REQUIREMENTS 

Here we consider the set of performance requirements that have been compiled for the MODIS 
data system. These performance requirements follow as a natural consequence of the func- 
tional requirements. They specify the requirements for response times, throughput capabilities, 
storage capacities, and other parameters that relate to the performance of the system. For 
the MODIS data system, they apply to the entire MODIS data system, specific elements of the 
data system (the CDHF, DADS, ICC, TMCF, and 1ST), and processes or functions within each 
element. The performance requirements are dependent on both the MODIS Science and 
Instrument Team requirements and EosDIS standards. Examples of quantitative performance 
requirements include overall system response times, communications link and processor 
throughput capabilities, and data storage capacities. Such performance measures can be 
specified both for the overall system operating as a whole and for the individual components 
that make up the system. Performance requirements are determined by the MODIS Science 
and Instrument Team members and by the various EosDIS organizations and committees that 
set standards and goals for all data systems supporting Eos instruments (including MODIS). 
Ultimately, many of the specific performance requirements for individual MICACS system 
components shall be derived by the MICACS Study Team from more general requirements on 
overall system performance stated by the MODIS Science and Instrument Teams. 

In addition to qualitative statements describing the general structure and design features of 
the MIDACS, a complete specification of that system includes specific quantitative measures of 
the required performance that the overall system and its individual components must achieve. 
While it is still very early in the Phase B study and many qualitative features of the system 
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and its components are still being defined, some quantitative measures of required performance 
have been given, and these early statements can be used as the basis of a very preliminary 
set of original and derived MIDACS performance requirements. A complete statement of 
requirements shall not be available until the completion of Phase B studies; indeed, it is the 
goal of the MIDACS Phase B study to produce a system specification that defines all aspects 
of required system performance. 

The following two figures illustrate in a very general sense the relationship between various 
aspects of the MODIS data system and the EosDIS. Figure 9 presents the interactions 
between the 1ST, the ICC, and the EMOC. We see observation requests originating from the 
1ST being passed to the ICC. From the ICC, schedule data is then forwarded to the EMOC, 
which must then respond with the command confirmation. The ICC then provides a response 
to the 1ST. In Figure 10, the primary downlink data flows between the relevant EosDIS, 

MODIS data system, and the science community are portrayed; specifically, the DHC, MODIS 
ICC, CDHF, DADS, and the data users. These relationships become important (in addition to 
the functional requirements for the data system elements) in developing a complete set of, and 
logical flow between, the performance requirements. Appendices D and E extend the prelim- 
inary view of the various data flows that occur throughout the system; the emphasis here is 
on high rate data flows that require special consideration in the design of the MIDACS. 
Appendix E contains a very preliminary computation of required processor capability based on 
the data rates projected in Appendix D and estimated computational path lengths for MIDACS 
data products, as well as the data storage capability required to support the system given the 
earlier defined data rates. Since many specifics are yet to be defined, all numbers in this 
report are initial estimates based on preliminary and incomplete information. Revisions shall 
undoubtedly occur as system needs are more realistically and specifically defined. 

At the present time, we have accumulated on the order of 280 functional requirements for the 
MODIS data system and its elements. There are, at present, only about 70 performance 
requirements for the system. Many of the performance requirements are specified only in a 
general sense, with the precise details of the performance requirements left "TBD." Moreover, 
the individual requirements, compiled from different sources, are sometimes in conflict, or 
overlap, with each other. A continued refinement of these performance requirements shall 
occur throughout this Phase-B data system study. 

4.1 INSTRUMENT SUPPORT TERMINAL (1ST) 

The 1ST is responsible for two basic functions: (1) science planning and coordination and (2) 
instrument performance evaluation. 

PRR1: There shall be at least one 1ST to support MODIS. 

4.1.1 Science Planning and Coordination 

4.1. 1.1 Planning Data 

4.1. 1.2 Observation Plan Coordination 

4.1. 1.3 Observation Requests 

4.1.2 Instrument Performance Evaluation 

4.1.2.1 Instrument State-of-Health Analysis 

4. 1.2.2 Instrument Model Parameters Maintenance 
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Figure 9. Primary Command Data Flows 
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Figure 10. Primary Downlink Data Flows 



4.2 INSTRUMENT CONTROL CENTER (ICC) 


The ICC is responsible for two basic functions: (1) operations planning and scheduling and (2) 
instrument control and monitoring. 

PRR2: There shall be an ICC dedicated to MODIS. 

4.2.1 Operations Planning and Scheduling 

4.2.1. 1 Observation Requests 

PRR3: The ICC shall provide the 1ST confirmation of the correctness and feasibility of 
observation requests within TBD of the receipt of the request. SOURCE: Reference 12, p. 51. 

PRR4: The ICC shall respond to a request for near-real-time data products within the 
time period of one orbit. SOURCE: Reference 5, Req. 32; Reference 6, p. 5. 

4.2.1.2 Instrument Time-Line Generation 

4.2.1.3 Resource Requirement Generation 

PRR5: The ICC shall disseminate to the EMOC within TBD minutes the detailed schedule 
for the MODIS instrument after receipt of the EMOC resource envelope. SOURCE: Reference 
12, p. 51. 

4.2. 1.4 Schedule Request Generation 

PRR6: The ICC shall, upon receipt of a reschedule request from EMOC, generate an 
updated command load associated with a MODIS instrument schedule within TBD minutes. 
SOURCE: Reference 12, p. 51. 

4.2.1.5 Command Sequence Generation 

PRR7: The ICC shall generate target-of-opportunity commands in near real-time. 

SOURCE: Reference 3, p. 52. 

PRR8: The ICC shall forward unconditionally allowable commands in real-time. SOURCE: 
Reference 7, p. 5-15. 

PRR9: For commands, loop delays shall not be more than 10 seconds between command 
delivery and received response. SOURCE: Reference 2 (ICC Facility). 

PRR10: In some cases, instrument command decisions will have to be made within the 
time period of one orbit. SOURCE: Reference 6, p. 45. 

PRR11: The ICC shall automatically generate, or select from sets of predefined command 
sequences, a safing command sequence for transmission to the EMOC within TBD seconds. 
SOURCE: Reference 12, p. 51. 

PRR12: The ICC shall provide a new command sequence within TBD hours in response to 
a schedule change directed by the MODIS Instrument Team leader. SOURCE: Reference 2 

(ICC Facility). 
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4. 2. 1.6 Reference Monitoring Profile Generation 

4.2. 1.7 Mission Planning Information 

4.2.2 Instrument Control and Monitor 

4.2.2.1 Instrument State-of -Health Monitoring 

PRR13: The ICC shall assess the quality of science data in near real-time for selected 
samples of data. SOURCE: Reference 7, p. 5-16. 

4.2.2.2 Engineering Trend Analysis 

4.2.2.3 Command Processing 

PRR14: The ICC shall monitor instrument status and confirm responses to uplink com- 
mands in near real-time. 95% of the real- time data broadcast by the satellite should be 
received, preprocessed, and displayed within 60 seconds from the transmission. SOURCE: 
Reference 6, p. 4. 

4.2.2.4 Displays and Status Reports 

PRR15: Raw instrument data from the DHC shall be immediately processed to provide a 
select set of graphic data products that are useful in assessing the instrument function. The 
exact data presentations to be supported are TBD. SOURCE: Reference 12, p. 51. 

PRR16: An alarm shall be generated by the ICC within TBD seconds, upon receipt of 
engineering data and other input data for each scene, to inform the 1ST and EMOC whenever 
an operation parameter exceeds the allowable range. SOURCE: Reference 12, p. 51. 

PRR17: The ICC shall generate an alarm, upon receipt of status information about 
EMOC, PSC, TDRSS, or other instruments from the EMOC, indicating anomaly condition which 
may affect the operation of the MODIS instrument within TBD seconds. This alarm shall be 
forwarded to the 1ST. 

PRR18: The ICC shall, upon request from the 1ST or EMOC, generate an instrument SOH 
report based on engineering data covering that period within TBD minutes. SOURCE: 
Reference 12, p. 51. 

PRR19: The ICC shall, upon request from the 1ST, generate an instrument operational 
history report using data quality assessments (DQA), engineering data, detailed schedule 
information, and commands, within TBD minutes. SOURCE: Reference 12, p. 51. 

4.3 TEAM MEMBER COMPUTING FACILITY (TMCF) 

The TMCF is responsible for three basic functions: (1) develop and maintain 
science/calibration algorithms, (2) validate/verify data, and (3) plan and coordinate. 

4.3.1 Develop and Maintain Science/Calibration Algorithms 

4.3.1. 1 Develop Algorithms 
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4.3.1. 2 Test and Modify Algorithms 


PRR20: The TMCF shall verify that the pointing accuracy of the MODIS instrument data 
sets is within the required accuracy of TBD kilometers. 

4.3.1.3 Implement and Certify Algorithms 

PRR21: The TMCF shall provide the CDHF with calibration coefficients in sufficient time 
such that Level-1 B data processing can occur on schedule. 

4.3.2 Verify/Validate Data 

4.3.2.1 Receive and Catalog Data Inputs 

4.3.2.2 Produce Special Data Products 

4.3.2.3 Perform Statistical Studies and Modeling 

4.3.3 Plan and Coordinate 

4.3.3.1 Receive Requests and Catalog 

4.3.3.2 Sort and Set Priority of Requests 

4.3.3.3 Develop Science Management Plan 

4.3.3.4 Send Requests 

4.4 CENTRAL DATA HANDLING FACILITY (CDHF) 

The CDHF is responsible for three basic functions: (1) receive DHC data, (2) produce data 
products, and (3) control process and handle data. 

4.4.1 Receive DHC Data 

4.4. 1.1 Ingest Data 

4.4.1.2 Perform Acceptance Checking 

4.4. 1.3 Reformat Data and Append Header 

4.4.2 Produce Data Products 

PRR22: All near-real-time data processing shall be completed within three to eight hours 
at all levels (Levels-IA to -3). The precise timeliness requirements will depend on the 
specific data requirements of the field experiment. SOURCE: Reference 19. 

PRR23: The data system shall be sized to support 15 simultaneous field experiments each 
for MODIS-N and MODIS-T: five for atmospheric sciences, five for oceanography, and five 
for land-sciences (a total of 30). SOURCE: Reference 19. 

PRR24: For each field experiment supported, a set of scenes shall be generated. A 
scene is defined as having the dimensions of a full cross-track scan width (i.e., 1294 pixels or 
about 2,000 km) by 2,000 kilometers (i.e., about 2,048 one-kilometer detector swaths or five 
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minutes of data). A set of scenes shall include the calibrated and Earth-located (Level- IB) 
radiances for 15 to 20 spectral channels, 25 Level-2 parameters, and TBD Level-3 products. 
SOURCE: Reference 19. 

PRR25: The CDHF shall be sized to be capable of simultaneously supporting processing, 
reprocessing, backlog processing, near-real-time processing, browse processing, and normal 
system maintenance. 

PRR26: The CDHF shall be sized such that it will not be utilized in excess of 70% of 
the system’s processing capacity. SOURCE: Reference 3. 

PRR27: The Level-1 processor shall have the capacity to process 24 hours of playback 
data within 8 hours after receipt of the data. SOURCE: Reference 3, p. 6-25. 

PRR28: The Levels-2, -3, and -4 processors shall each have the capacity to process 24 
hours of data within 12 hours of the next 24-hour period. 

PRR29: The CDHF shall routinely process standard products. 

4.4.2.1 Process Level-1 A 

PRR30: The amount of Level-0 data to be processed to Level-IA is equal to TBD times 
the raw MODIS instrument data. 

PRR31: All Level-0 data sets received within a 24-hour period shall be completely Lcvcl- 
1A processed within 12 hours. 

PRR32: Results of Level-IA processing shall be available to authorized investigators 
within 48 hours of the original observation. 

4.4.2.2 Process Level-IB 

PRR33: The amount of Level-IA data to be processed to Level-IB is equal to TBD times 
the raw MODIS instrument data. 

PRR34: All Level-IA data sets received within a 24-hour period shall be completely 
Level-IB processed within 12 hours. 

4.4.2.3 Process Level-2 

PRR35: The amount of Level-IB data to be processed to Level-2 is equal to TBD times 
the raw MODIS instrument data. 

PRR36: All Level-IB data sets received within a 24-hour period shall be completely 
Level-2 processed within 8 hours. 

4.4.2.4 Process Level-3 

PRR37: The amount of Level-2 data to be processed to Level-3 is equal to TBD times 
the raw MODIS instrument data. 

PRR38: All Level-2 data sets received within a 24-hour period shall be completely Level- 
3 processed within 8 hours. 
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4.4.2.5 Process Level-4 


PRR39: The amount of Level-3 data to be processed to Level-4 is equal to TBD times 
the raw MODIS instrument data. 

4.4.3 Control Processing and Handle Data 

4.4.3.1 Receive Data 

4.4.3.2 Catalog and Store Data 

PRR40: The CDHF shall provide a storage system utilizing fast access storage for on- 
line working storage and for protection against data loss. 

PRR41: The CDHF shall be capable of storing data at the volume of TBD Gbytes/day in 
its data store to facilitate retention of data, algorithms, and products. 

4.4.3.3 Distribute Data 

4.4.3.4 Control Processing 

PRR42: Investigator processing requests for near-real-time data should be completed 
within the time frame of one orbit. SOURCE: Reference 6, p. 10. 

PRR43: All data shall be reprocessed a maximum of two times during the 20-year 
mission. [Clearly, this EosDIS assumption is questionable. Past experience indicates that data 
sets may be reprocessed more than twice; for example, as improved calibration algorithms and 
geophysical parameter retrieval algorithms become available.] 

4.5 DATA ARCHIVE AND DISTRIBUTION SYSTEM (DADS) 

The DADS is responsible for four basic functions: (1) receive data, (2) manage data, (3) 
process user requests, and (4) distribute data. 

4.5.1 Receive Data 

4.5. 1.1 Ingest Data 

4.5.1. 2 Perform Acceptance Checking 

4.5.1.3 Process Headers 

4.5.1.4 Organize Data 

PRR44: The DADS catalog will be updated with the information provided by the data set 
producing organization as soon as practical (i.e., daily). The catalog entry associated with 
each archive data set shall be inserted into the catalog as the data set is inserted into the 
archive. SOURCE: Reference 13, p. 4-25. 
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4.5.2 Manage Data 


4.5.2. 1 Store Data 

PRR45: The DADS archive shall maintain data on media that provide long lifetimes, rapid 
and random access, and economical storage. SOURCE: Reference 5, Req. #0270. 

PRR46: The DADS shall provide a data storage system using slow access with buffering. 
SOURCE: Reference 3, p. 6-14. 

PRR47: The DADS shall size base system for a user community of 1,000 to 10,000; 50 to 
200 active at any time, ordering 5 to 10 tapes per month; 1 to 10 users ordering large volumes 
of data and handle up to 100 simultaneous users. SOURCE: Reference 5, Req. #0324. 

PRR48: The DADS shall be capable of storing data at the volume of TBD Gbytes/day in 
its data store to facilitate retention of data and products. SOURCE: Reference 12, p. 54. 

PRR49: The average and maximum total archive data retrieval volume for electronic 
distribution is estimated to be TBD GBytes. 

4.5.2.2 Manage Catalog 

PRR50: The number of catalog entries to be managed by the DADS is TBD. 

4.5.2.3 Report Status 

4.5.3 Process User Requests 

4.5.3.1 Receive User Requests 

PRR51: The estimated daily number of retrieval orders for electronic distribution is TBD. 

PRR52: The DADS shall handle up to 100 simultaneous interactive 
catalog/browse/ordering system users. SOURCE: Reference 6, p. 47. 

PRR53: The DADS shall provide for interactive, electronic catalog and ordering functions 
with a minimum 9600 bps dial-up capability. SOURCE: Reference 5, Req. #37. 

PRR54: The amount of queries supported by the DADS is TBD. SOURCE: Reference 13, 
p. 4-29. 


PRR55: The archive shall be accessible from remote terminals or workstations via a 
prompting menu or natural language interface, supplemented by a free-form command language 
for experienced users. SOURCE: Reference 5, Req. #0236. 

4.5.3.2 Generate Order Status 

4.5.3.3 Retrieve Data 

PRR56: An interactive catalog system should provide a response to most search com- 
mands within 1 to 15 seconds. SOURCE: Reference 6, p. 11. 

PRR57: Response time of the DADS to a user should be timely, and shall be limited by 
the search capability of the system. SOURCE: Reference 3, p. 2-27. 
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4.5.4 Distribute Data 


PRR58: The DADS shall be capable of satisfying the need for data by multiple users, 
each user possibly requiring a different time line and path. SOURCE: Reference 5, Req. 
#008. 


PRR59: The retrieval and transfer of catalog information shall be accomplished with a 
bit error rate of TBD. [10* 12 ?] 

PRR60: Near-real-time processed data shall be required for operational purposes, and 
may be of value for interactive browse activities. SOURCE: Reference 6, p. vii. 

PRR61: Browse files should be visually searchable via attributes (e.g., day, position, time, 
channel, parameter') and by an expert system. SOURCE: Reference 6, p. 47. 

PRR62: On-line browse capabilities may not be possible for many users; this shall 
necessitate publication of an image browse catalog. SOURCE: Reference 6, p. 47. 

PRR63: It is a goal that the DADS retrieve the first data set of the order and start the 
transmission of the data set for orders requesting on-line data within 40 seconds of receipt of 
the order for 50 percent of all orders and within 100 seconds for 90 percent of all orders. 
SOURCE: Reference 13, p. 4-19. 

PRR64: The DADS shall be capable of retrieving the products, including associated 
ancillary data, for a scene ordered by the user and make them available for dissemination to 
the user or DDC in less than an hour upon receipt of the product order. SOURCE: Refer- 
ence 12, p. 54. 

PRR65: The DADS will retrieve the first data set of orders for off-line data within 30 
minutes for 90 percent of all such orders. 

4.5.4. 1 Generate Direct Product 

PRR66: The DADS shall be capable of responding to orders requesting archive data on 
tape, optical disk, or listings within three working days. The DADS shall receive and process 
these orders in terms of locating the requested data, producing them on the request medium, 
preparing them for mailing, and properly accounting for their production. SOURCE: Refer- 
ence 13, p. 4-20. 

4. 5.4.2 Transmit Data 

PRR67: The DADS will transmit electronic orders which do not require interactive 
servicing (e.g., data retrieved for recalibration) at convenient times. SOURCE: Reference 13, 
p. 4-20. 

PRR68: The DADS shall be capable of providing a minimum requirement (or maximum 
response time) for all archive data orders placed electronically requiring interactive servicing 
and requesting on-line data (e.g., browse data). SOURCE: Reference 12, p. 54; Reference 13, 
p. 4-19. 
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4.6 ON-BOARD PROCESSING 


PRR69: On-board compression of the MODIS instrument data shall be applied if neces- 
sary to insure that the maximum and mean data rates do not exceed TBD and TBD Mbps, 
respectively. 

5. SYSTEM INTERFACE REQUIREMENTS 

Each MIDACS element (1ST, ICC, TMCF, CDHF, and DADS) is a logical entity that performs a 
particular subset of required MIDACS functions. The division of overall system function 
among modules dedicated to instrument control, data processing, data storage and retrieval, 
etc. presents a natural opportunity to select separate, specialized hardware components for 
each module. Each hardware unit can then be chosen to provide support specifically tailored 
to a corresponding software function. And distinct hardware components naturally allow the 
physical separation of MIDACS elements when remote access is needed. Therefore, the initial 
MIDACS design is being specified to allow the possibility that each MIDACS element will be a 
physically distinct entity. 

If each MIDACS element is physically distinct, then the data interfaces shown in the overall 
MIDACS context diagram and the MIDACS element context diagrams are not just logical 
interfaces, but physical interfaces as well. The logical structure of the system and the 
general nature of interfaces is documented in the data flow diagrams and the corresponding 
data dictionary descriptions of the data flows. The interested reader is referred to the 
appropriate sections of this document where these documents are included. Beyond that, this 
section of the document contains two additional items pertaining to MIDACS interfaces: short 
statements of specific interface requirements extracted from earlier MIDACS documents 
(similar to the requirements listed elsewhere in this document) and interface tables listing 
each physical interface and giving qualitative descriptions of required data transmission 
capability for each interface. Section 5.1 contains a list of extracted interface requirements 
generally applicable to the entire data system. Section 5.2 (Internal Interfaces) and section 
5.3 (External Interfaces) each begin with charts showing qualitative characteristics of the 
required interfaces. Each section then concludes with a list of extracted requirements 
applying specifically to that type of interface. 

5.1 GENERAL REQUIREMENTS 

SSR1: The TMCF shall supply the CDHF with the calibration and scientific algorithms as 
they are developed. These algorithms will be updated during the course of the mission as 
required. SOURCE: Reference derived from FNR85. 

SSR2: The TMCF shall supply DADS with the calibration and scientific algorithms as 
they are developed and information on how they were used in the data processing. SOURCE: 
Reference derived from FNR85. 

SSR3: The interface shall maximize opportunities for commonality within the system and 
ensure flexibility in the implementation of the interface. (Level I REQ# 1.2.3) 

SSR4: The interface shall use standard, off-the-shelf hardware and software wherever 
possible to facilitate modernization during the system’s lifetime. (Level I REQ# 1.2.4) 

SSR5: The interface shall make maximum practicable use of standards for data structures 
and data transport defined for use within the Space Station Information System (SSIS), the 
International Standard Organization’s open system concept, and the publications of the 
Consultative Committee for Space Data Systems (CCSDS). (Level I REQ# 1.2.5) 
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SSR6: The interface shall be designed to accommodate growth in instrument data rates 
and volumes. (Level I REQ# 2.1.1) 

SSR7: The interface shall be technologically transparent. (Level I REQ# 2.1.2) 

SSR8: The MIDACS shall provide a convenient and effective interface to the user and 
scientist which optimizes their access to data, information, and resources available for their 
use. (Level I REQ# 2.3.14) 

5.2 INTERNAL INTERFACES 

Table 1 lists four qualitative characteristics for each internal interface within the MIDACS. 

The first item listed is estimated data transfer rate, roughly characterized as low, moderate, 
or high. While the specific quantitative intervals to be associated with each designation can 
not be defined until more complete studies are completed, rough descriptions of each data-rate 
category can be given. Generally, low data rates are understood to include rates suitable for 
transmitting textual or other human-interpretable coordination materials with limited numerical 
or machine-readable content. High data rates are understood to be roughly within an order of 
magnitude of the MODIS instrument average data rates, perhaps greater than 1 Mbps or so. 
Moderate rates are between the extremes, data rates requiring machine interpretation for 
effective utilization, but not an appreciable fraction of the full MODIS instrument data rate. 

The Frequency of Use parameter is characterized as either Occasional or Regular. Regular use 
is understood to mean that communications resource sharing could not be effectively employed 
and that only dedicated resources could be employed. Occasional use is obviously something 
less than Regular Use. 

The data Timeliness Requirement is characterized as either Real-Time, Near-Real-Time, or 
Routine. Real-Time data is understood to be data that is needed essentially as it becomes 
available with only minimal storage delays in data transmission buffers. Near-Real-Time data 
is data that must be completely processed within 3 to 8 hours, so that some minimal transmis- 
sion delay is acceptable, but definite time limits exist, and the entire processing routine must 
be completed within these time limits. For Routine Processing, data storage is allowed, and 
data can be queued to await processing. Routine processing is variously defined to be 
processing that must be completed within 24 or 48 hours. 

Two data path length designations are defined: Local means essentially that data path require- 
ments are not greater than building-to-building communications on a particular campus. All 
other communications are listed as Remote. Links that could be either Local or Remote have 
been listed as Local/Remote. 

5.2.1 ICC - 1ST Interface 

SSR9: The ICC shall send instrument monitoring informations and displays to the 1ST for 
further investigation of instrument anomalies. Reference 16 p. 5-17. 

SSR10: The 1ST shall submit observation requests to the ICC. Reference 16, p.5- 17. 

SSR11: The 1ST shall submit emergency command requests to the ICC. Reference 16, p. 

5-17. 

SSR12: The 1ST shall provide the ICC with updates to monitoring algorithms. Reference 
10, p-7. 


70 



MIDACS Internal Interfaces 
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KEY: Transfer Rate 

Frequency of Use 
Timeliness Requirement 
Path Length 



SSR13: The ICC shall send to the DADS a history of commands and command loads. 
Reference 3, p. 5-17 and Reference 8, p. 5-12. 

SSR14: The DADS shall receive data from the ICC pertaining to command load histories. 
SOURCE: Reference 3, p 5-17. 

5.2.2 ICC - CDHF Interface 

SSR15: The ICC will receive data quality assessments of science data from the CDHF. 
SOURCE: Reference ? 

SSR16: The ICC will provide the CDHF with discipline data timelines of planned 
observation schedules. SOURCE: Reference ? 

5.2.3 1ST - TMCF Interface 
(TBD) 

5.2.4 DADS - TMCF Interface 

SSR17: The DADS shall receive data products and ancillary data from the TMCF. 
SOURCE: Reference 3, p. 2-23. 

SSR18: The DADS shall receive algorithms and calibration parameters for archive from 
the TMCF. SOURCE: Reference 3 

5.2.5 TMCF - CDHF Interface 
(TBD) 

5.2.6 DADS - CDHF Interface 

SSR19: The DADS shall receive processed data and ancillary data from the CDHF. 
SOURCE: Reference 3. 

SSR20: The DADS shall receive browse data from the CDHF. SOURCE: Reference 3. 

SSR21: The DADS shall receive calibration data from the CDHF. SOURCE: Reference 3 

SSR22: The DADS shall send post-archive data to the CDHF for reprocessing. SOURCE: 
Reference 3 

5.2.7 CDHF - DADS Interface 
(TBD) 

5.3 EXTERNAL INTERFACES 

Tables 2 and 3 list the qualitative characteristics for each external interface within the 
MIDACS. Table 2 includes links originating within the MIDACS and terminating outside of the 
MIDACS. Table 3 includes links originating outside of the MIDACS and terminating within the 
MIDACS. 
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RECIPIENT 


Table 2 


MIDACS External Interfaces 
Qualitative Data Transfer Characteristics 

ORIGINATOR 

1ST ICC TMCF CDHF DADS 


IMC 

EMOC 

DHC 

Non- 

EOS 

Other 

EOS 

Perm. 

Archive 

Users 


Low 

Occasional 
Routine 
Local /Remote 

Low 

Occasional 

Routine 

Local 

Low 

Occasional 
Routine 
Local / Remote 

Low 

Occasional 

Routine 

Local 

Moderate 

Regular 

Routine 

Local 


Moderate 

Occasional 

Real-Time 

Local 





Low 

Occasional 

Real-Time 

Local 


Low 

Occasional 

Real-Time 

Local 




Low 

Occasional 
Routine 
Local /Remote 







High 

Occasional 
Routine 
Local /Remote 





High 

Occasional 
Routi ne 
Local /Re mote 

Low 

Occasional 
Routine 
Local /Remote 




Moderate 
Occasional 
Routine 
Local /Remote 


KEY: 


Transfer Rate 
Frequency of Use 
Timeliness Requirement 
Path Length 
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ORIGINATOR 


Table 3 


MIDACS External Interfaces 
Qualitative Data Transfer Characteristics 


1ST ICC 


RECIPIENT 

TMCF CDHF DADS 


IMC 

EMOC 

DHC 

Non- 

EOS 

Other 

EOS 

Perm. 

Archive 

Users 


Low 

Occasional 
Routi ne 
Local /Re mote 

Low 

Occasional 
Routi ne 
Local 

Low 

Occasional 
Routine 
Local /Remote 

Low 

Occasional 

Routine 

Local 

Low 

Occasional 
Routi ne 
Local 


Low 

Occasional 
Routi ne 
Local 





High 
Regular 
Real-Ti me 
Local 


High 

Regular 

Near- Real /Routi ne 
Local 




Moderate 
Occasional 
Routine 
Local /Remote 


Moderate 
Occasional 
Routine 
Local /Remote 





High 

Occasional 
Routi ne 
Local /Remote 





High 

Occasional 
Routi ne 
Local /Remote 

Low 

Occasional 
Routi ne 
Local /Remote 






KEY: 


Transfer Rate 
Frequency of Use 
Timeliness Requirement 
Path Length 
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5.3.1 EMOC to ICC interface requirements 


SSR23: The ICC shall provide instrument operations planning inputs to EMOC. (Reference 
3, p. 2-21). 

SSR24: The EMOC shall provide a consolidated plan for MODIS operations to the ICC. 
(Reference 3, p. 5-21). 

SSR25: The ICC shall provide a detailed schedule for the MODIS operations to EMOC. 
(Reference 3, p. 2-18). 

SSR26: The EMOC shall provide a conflict-free schedule developed by the PSC to the 
ICC (Reference 3, p. 5-23). 

SSR27: The ICC shall transmit instrument commands to EMOC. (Reference 3, p. 2-18). 

SSR28: The exchange of data and information between the MIDACS ICC and EMOC shall 
be through the NASA communication networks. (Reference 3, p. 5-28). 

SSR29: The ICC shall transfer selected portions of instrument engineering data to EMOC 
to support its monitoring role. (Reference 3, p. 5-33). 

SSR30: The ICC shall provide instrument status information to EMOC (Reference 3, p. 

5-15). 

SSR31: A detailed schedule shall be iterated between the EMOC and the ICC until 
approved. Reference 12. 

SSR32: The EMOC and ICC shall maintain informational interfaces for relay of messages 
and management information. Reference 12. 

SSR33: The ICC shall send emergency command loads to the EMOC. Reference 3, p 5-26 

SSR34: The EMOC shall allocate current resource envelopes to the ICC. These envel- 
opes may include power, thermal, tape recorder, and LAN usage, as well as, guidelines for 
scheduling. Reference 3, p 5-21,23 

SSR35: The EMOC shall send the ICC status data. Reference 10, p-6 
SSR36: The EMOC shall provide the ICC with the platform status data. Reference 12. 
5.3.2 DHC to ICC Interface Requirements 

SSR37: The DHC shall provide the ICC with Level-0 processed platform engineering data 
and Level-0 processed payload engineering data. (Reference 3, p. 5-33) 

SSR38: The DHC shall provide the ICC with real-time engineering data in real time. 
(Reference 3, p. 5-33) 

SSR39: The DHC shall provide the consolidated and checked ancillary data packets to 
the ICC. (Reference 3, p. 5-31) 
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5.3.3 DHC to CDHF Interface Requirements 

SSR40: The exchange of data and information shall be effected through the NASA 
communication networks. (Reference 3, p. 5-33) 

SSR41: The DHC shall transmit Level-0 science data to the CDHF. (Reference 3, p. 

5-33). 

SSR42: The DHC shall transmit the consolidated and checked ancillary data packets to 
the CDHF. (Reference 3, p. 5-31) 

5.3.4 IMC to MID ACS Interface Requirements 

SSR43: The MIDACS shall provide, in a timely fashion to the IMC, all the information 
on the data products generated by the MIDACS which include standard data products from 
CDHF, specialized products from TMCF, calibration products, algorithms used for generating 
data products, processing status, and necessary documentation. The DADS shall use already 
existing internal interfaces to collect from these facilities all the information needed by the 
IMC or users. SOURCE: Reference 3, p. 2-23,25. 

5.3.5 Permanent Archives to DADS Interface Requirements 

SSR44: The DADS shall transfer all the products in its archive to permanent archives 
(which need to be identified) after TBD years of active archival. (Reference 3, p. 3-12) 

5.3.6 Other DADS to MIDACS Interface Requirements 

SSR45: MIDACS functional elements shall be able to receive ancillary and/or correlative 
data from other EosDIS/DADS (which need to be identified) through first interrogating the 
IMC to locate data sources and availability. DADS may assume the role of contacting IMC 
and receiving data from other DADS and then relaying them to other MIDACS elements. 
SOURCE: Reference 5, Req. 7,30. 

5.3.7 Non-Eos Data Sources to MIDACS Interface Requirements 

SSR46: MIDACS functional elements shall be able to receive ancillary and/or correlative 
data from other EosDIS/DADS (which need to be identified) through first interrogating the 
IMC to locate data sources and availability. The DADS may assume the role of contacting 
IMC and receiving data from other DADS and then relaying them to other MIDACS elements. 
SOURCE: Reference 5, Req. 7,30. 

5.3.8 User to MIDACS Interface Requirements 

SSR47: The DADS shall deliver requested data products, documentation, algorithms, 
and/or data processing status to the users electronically or via off-line storage media. 

SOURCE: Reference 3, p. 5-40,43. 

SSR48: Users wishing to have particular configuration of the MODIS instrument shall 
contact the MODIS instrument team leader for scheduling of the instrument operations. 
SOURCE: Reference TBD. 

6. PHYSICAL REQUIREMENTS 

(TBD) 
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7. DELIVERY AND INSTALLATION REQUIREMENTS 

(TBD) 

8. DESIGN AND IMPLEMENTATION REQUIREMENTS 

DSRl: The first architectural principle to be applied throughout the design of the 
EosDIS is layering. Layering breaks the diverse and complex system into easily comprehen- 
sible modules with clear "strata" in which common data handling functions reside. SOURCE: 
Reference 6, page 16. 

DSR2: The second architectural design principle is standardization of formats and 
protocols through which data are exchanged between distributed elements of the system. 
SOURCE: Reference 6, page 16. 

DSR3: Computer hardware should change when necessary to keep overhead low and to 
improve system capability. Software and procedural changes triggered by such hardware 
changes should be planned; benchmark tests and standard data sets for reprocessing should be 
defined to verify the operation of the whole system after such changes occur. SOURCE: 
Reference 6, page 25. 

DSR4: The data processing architecture shall have a high degree of modularity and 
structure in order to have the adaptive flexibility required for the evolving character of data 
processing requirements. SOURCE: Reference 3. 

DSR5: The ICC shall be designed for change; accommodating new hardware and software 
due to new instruments. Changes shall be controlled and documented. Change procedures 
shall be clearly defined. SOURCE: Reference 2 (ICC Facility). 

DSR6: The MODIS ICC shall be colocated with the EMOC. SOURCE: Reference 2 (ICC 
Facility). 

DSR7: The DADS requirements for ground storage functions can be met with commercial 
disk and tape drives ensuring conservative technological improvements. SOURCE: Reference 3 

p. 6-18. 

DSR8: The architectural approach of the CDHF shall be multi-tiered, using a layered 
network to meet the need for a limited number of widely used standard products and simultan- 
eously distribute low level data to local or regional processing centers for generation of 
research or specialized products. SOURCE: Reference 6, p.60. 

DSR9: Processing capacity and performance shall be capable of flexible enhancement to 
meet evolving needs defined by instrument teams. SOURCE: Reference 6, page vii. 

DSR10: The DADS design and location shall be such as to provide for a smooth transi- 
tion of archiving responsibility from the MIDACS to the permanent archive facility. SOURCE: 
Reference 3, p. 2-23. 

DSR11: The DADS shall either be colocated with an existing permanent archive facility 
or electronically tied to such a facility. SOURCE: Reference 3, p. 5-35. 

DSR12: The MIDACS design must provide proper access security of data. SOURCE: 
Reference 6, p. 28, and p.46. 
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DSR13: The DADS shall size base system for a user community of 1,000 to 10,000; 50 to 
200 active at any time, ordering 5 to 10 tapes per month; 1 to 10 users ordering large volumes 
of data and handle up to 100 simultaneous users. SOURCE: Reference 5 (Req. No. 0324). 

DSR14: Interactive scheduling tools for command sequence design and integration shall 
be developed for the ICC. 

DSR15: The ICC shall be a dynamic system, capable of accommodating the growth and 
evolution of spacecraft instrumentation, technology, and user requirements. SOURCE: 
Reference 2 (ICC Facility). 

DSR16: The ICC shall meet the following reliability, maintainability, and availability 
requirements: TBD. SOURCE: Reference 2 (ICC Facility). 

9. DEVELOPMENT PLAN 

9.1 OVERALL APPROACH TO DEVELOPMENT AND IMPLEMENTATION 

(TBD) 

9.1.1 Delivery 
(TBD) 

9.1.2 Installation 
(TBD) 

9.1.3 Acceptance Testing 
(TBD) 

9.2 DOCUMENTATION 

(TBD) 

9.3 TIME FRAMES AND MILESTONES 

(TBD) 

9.4 PARTICIPATION BY OTHER ORGANIZATIONS 

(TBD) 
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APPENDIX A 
LIST OF ACRONYMS 


bps 

bits per second 

CCSDS 

Consultative Committee for Space Data Systems 

CDA 

Command and Data Acquisition 

CDHF 

Central Data Handling Facility 

CDOS 

Customer Data and Operations System 

CST 

Calibration Support Team 

DADS 

Data Archive and Distribution System 

DDC 

Discipline Data Center 

DHC 

Data Handling Center 

DIF 

Data Interface Facility 

DLR 

Delivery and Installation Requirement 

DSR 

Design and Implementation Requirement 

EMOC 

EOS Mission Operations Center 

EOS 

Earth Observing System 

EosDIS 

EOS Data and Information System 

FNR 

Functional Requirement 

GSFC 

Goddard Space Flight Center 

IMC 

Information Management Center 

ICC 

Instrument Control Center 

1ST 

Instrument Support Terminal 

Mbps 

Megabits per second 

MIDACS 

MODIS Information, Data, and Control System 

MODIS 

Moderate Resolution Imaging Spectrometer 

MODIS-N 

MODIS nadir 

MODIS-T 

MODIS tiltable 

NASA 

National Aeronautics and Space Administration 

NCDS 

NASA Climate Data System 

NODS 

NASA Ocean Data System 

NLDS 

NASA Land Data System 

NPOP-1 

NASA Polar Orbiting Platform-1 

NSSDC 

National Space Science Data Center 

PHR 

Physical Requirement 

PRR 

Performance Requirement 
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PSC 

Platform Support Center 

SDMU 

Science Data Management Unit 

SOH 

State-of-Health 

SSIS 

Space Station Information System 

SRR 

System Requirement 

TBD 

To Be Determined 

TDRSS 

Tracking and Data Relay Satellite System 

TGT 

TDRSS Ground Terminal 

TMCF 

Team Member Computing Facility 
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APPENDIX B 
LIST OF ASSUMPTIONS 


(TO BE SUPPLIED) 
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APPENDIX C 

MODIS DATA SYSTEM DICTIONARY 


Accepted-Data 

Algorithm-Release-Announcement 


Analysis-Results 

Ancillary-Data 

Archive-Ancillary-Data 

Archive-Data-Products 

Archive-Data-Products-Release' 

Authorization 


*DADS ingested data that has been quality checked.* 

•Announcement to the team that a debugged, working 
processing algorithm is now in use, containing 
information such as version numbers, availability of 
user’s guide, etc.* 

•Results of analysis of instrument performance over 
a long period which reflects trends in performance.* 

•Data other than MODIS-Instrument-Data required to 
perform MODIS data processing (such as platform 
and other instrument data).* 

•Ancillary data retrieved from the MODIS DADS.* 

•MIDACS products routinely archived for potential 
user access and distributed in response to a product 
request.* 

•Authorization to release data products in the DADS 
to data users.* 


Archive-Data-Request 


*A request for data to be retrieved from any EosDIS 
DADS* 


Authorized-Schedule-Data 


Automated-Command-Sequences 


Browse-Data 


Candidate-Observation-Sequence 


Catalog/Directory-Data 


*A schedule containing instrument resources and 
timelines, that have been approved by the EMOC 
through iteration with the ICC.* 

*A human readable sequence of commands generated 
by the planning and scheduling processes and used 
for the generation of command loads.* 

•Subsets of a data set other than the directory and 
metadata that facilitates user selection of specific 
data having the required characteristics. For 
example, image data of a single channel with 
degraded resolution.* 

*A human readable form of the instrument resources 
and timelines necessary to perform the observation 
request. These data are sent to the EMOC for 
approval.* 

*A description of data available from the MIDACS 
DADS listed by platform, instrument, data processing 
level, algorithm identifier, parameter, time, geo- 
graphic location, or combination.* 
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CDHF-Accepted-Data = Data from the DHC that has undergone TBD data 

validation checks. 

CDHF-Database-Inquiry = ‘Request for CDHF temporary storage catalog 

information.* 


CDHF-Database-Report 

CDHF-Data-Products 

CDHF-Ingested-Data 

CDHF-Stored-Data 

Command-Loads 


Command-Request 

Coordinated-Observation-Plan 


Correlative-Data 


Correlative-Data-Request 


Response to CDHF database inquiry. 

Levels 1-4 MODIS data products. 

‘Data received from the DHC that has been blocked 
by TBD methods.* 

‘Any subset of data sets cataloged and stored in the 
CDHF temporary storage.* 

‘Encoded MODIS instrument command sequences as 
required by the on-board MODIS instrument control 
system and constructed so as to affect a specific 
action; e.g., "HV PWR ON"..* 

*A command load generated by the 1ST, verified by 
the ICC, and immediately transmitted to the EMOC.* 

‘Any data received by the 1ST which has been 
selected as an observation request which has been 
coordinated to determine its consistency with the 
EOS science objectives.* 

‘Scientific data not from the MODIS instrument used 
to verify, interpret, or validate MODIS data 
products.* 

‘Information required to initiate and support the 
transfer of Correlative-Data to the requestor.* 


Critical-Command-Request 


DADS-Status-Inquiry 

DADS-Status-Report 


*A command request issued by the monitoring 
function when the state-of-health of the instrument 
or its performance is degraded.* 

‘Request for a specific type of DADS-Status-Report.* 

‘Description of the DADS status, resources utiliza- 
tion, and performance.* 


Data-Products-Release-Announcement= ‘Announcement to the team that a validated special- 
ized or correlative data product is available to the 
scientific community.* 

DHC-Data-Request = ‘Request to redesignate packet handling and 

processing priorities.* 
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I 


! Displays 

Distribution-Request 

DQA-Criteria 

DQA-Reports 

i 

Engineering-Data 

I 

Formatted-Observation-Request 

Generic-Observation-Request 

Geography-Data 

Headers 

ICC-Data-Request 

i 

I IMC-Inquiry 


IMC-Inquiry-Response 


* Plots, images, a list of requested data or status of 
the instrument or ground system communicated 
visually.* 

Request to send stored data, for production of 
MODIS data products, for archiving at the DADS or 
for use by the TMCF. 

*Factors used to assess data quality.* 

♦Results of routine data quality assessment associated 
with data receipt and data product operations* 

MODIS-Engineering-Data + 
Platform-Engineering-Data. 

*Any observation request received by the ICC that 
has been processed for input into the generation of 
instrument timelines.* 

♦Observation requests that are predetermined and are 
consistent with the original science plan.* 

♦Data that can be used to identify land and ocean 
boundaries or other Earth features necessary for the 
implementation or generation of the instrument 
commands. Used in generating instrument timelines.* 

♦Information about the attributes of standard, 
non-standard, or data products.* 

*A request for information from the ICC.* 


♦Request for information on the operational status of 
the MODIS instrument or the MIDACS data system.* 

Production-Status-Inquiries + 

DADS-Status-Inquiries + 

Observation-Plan-Inquiry + 
Instrument-Operational-Status-Inquiries 

Production-Reports + 

DADS-Status-Reports + 

Instrument-Status-Reports + 
Observation-Plan-Information 
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I 


Ingested-Data 


Instrument-Operational-Status 

Inquiry 

Instrument-Operations-Models 

Instrument-Status-Reports 

IST-Coordination 

Level-O-Data 

Level-IA-Data 

Level-1 B-Data 

Level-2-Data 

Level-3-Data 

Level-4-Data 

Management-Information 

Mission-Planning-Information 

MODIS-Data-Products 


= *A11 products and data received by the DADS.* 

MODIS-Data-Products + 

Specialized-Products + 

Permanent-Archived-Data + 

Correlative-Data + 

Ancillary-Data + 

Processing-Algorithms 

= *An inquiry made by the IMC to determine the 
status of the ICC and/or the MODIS instrument.* 

= *Computer-compatible mathematical analogs of the 
MODIS instrument, used to estimate resource 
requirements during a modeled operation.* 

= *Information on the operating configuration of the 
MODIS instrument.* 

= *Planning and performance information relating to 
the MODIS instrument.* 

= *MODIS-Instrument-Data at original resolution, time 
order restored, with duplicates removed.* 

■ *Level 0 data which are reformatted reversibly, with 
Earth location, solar and instrument zenith angle, 
calibration data, and other ancillary data appended.* 

= *Level-lA data to which the radiometric calibration 
algorithms have been applied, perhaps irreversibly, to 
produce radiances or irradiances, and to which the 
Earth-location and zenith-angle algorithms have been 
applied at the grid points.* 

= Geophysical parameter data derived from the Level- 
1B data by application of geophysical parameter 
algorithms. 

= Earth-gridded geophysical parameter data (including 
Level-1 radiances), which have been averaged or 
composited in time and space. 

= TBD analyses of the lower levels of MODIS data. 

» *Internal information about the DADS data store and 
catalog.* 

= instrument operations schedule; information provided 
by the ICC to the CDHF to verify receipt and 
specify complete handling of data sets.* 

= Levels 1-4 Data Products + 

Browse Data 
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MODIS-Engineering-Data 

MODIS-Instrument-Data 

MODIS-Science-Data 

Monitoring-Algorithms 

Monitoring-Database-Inquiry 

Monitoring-Database-Report 

Near-Real-Time-Data 

Near-Real-Time-Processing 

Near-Real-Time-Request 

Non-Standard-Products 

Observation-Plan-Coordination 

Observation-Plan-Information 

Observation-Plan-Inquiry 

Observation-Planning-Data 


= ‘Data other than MODIS-Science-Data generated 
within the MODIS instrument.* 

= *Data originating within the MODIS instrument.* 

= MODIS-Science-Data + 

MODIS-Engineering-Data 

= ‘Unprocessed observations as generated by the 
MODIS instrument.* 

= *A procedure for transforming information for 
processing and displaying MODIS science and 
engineering data for monitoring instrument 
performance. 

= ‘Inquiry of the monitoring database to determine 
what instrument monitoring reports, data, and 
analyses are currently available.* 

= ‘Report of instrument monitoring functions and 
availability.* 

= *MODIS-Instrument-Data designated for Priority 
Processing.* 

= ‘Processing accomplished within three to eight hours 
after input data become available.* 

= ‘Request to handle data in Priority Mode.* 

= ‘Products not routinely produced, standard products 
produced by an alternate algorithm, or combinations 
of standard products.* 

■ ‘Information exchange between a user requesting 
special MODIS services and the MODIS Instrument 
Team Leader. The exchange should culminate in a 
plan for MODIS Instrument Operation.* 

= ‘Information describing observations planned for the 
MODIS instrument.* 

= *A request for information on planned MODIS 
instrument observations.* 

- *Any data received by the 1ST which has been 

selected as a possible observation request which will 
undergo coordination to determine its consistency 
with the EOS science objectives.* 
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Observation-Request 

Observation-Resource-Requirements 

Orbit-&-Attitude-Data 

Order-Found-Status 

Order-Placed-Status 

Order-Status-Data 


Organized-Data 

Permanent-Archive-Data 
Permanent-Archive-Da ta-Request 
Planning-Input 

Platform-Engineering-Data 

Preliminary-Algorithms 

Preliminary-Specialized-Data- 

Products 

Priority-Processing 


*MODIS measurement request not covered by the 
current schedule or data handling procedures. The 
request is consistent with general science objectives 
and science mission plans and goals.* 

•Predicted instrument resources necessary to fulfill 
the objectives of the observation request.* 

♦Data that describes the current or predicted orbital 
position and pointing of the platform or instrument 
axes.* 

♦Status of the product order when located and 
retrieved. This information can be sent to the user 
via the IMC* 

♦Status of the Product Order when the user request 
has been processed. This information can be sent to 
the user via the IMC.* 

♦Status and billing of the product ordered through 
IMC* 

Order-Found-Status + 

Order-Placed-Status 

♦Data products which have been grouped according 
to the header, e.g.. Level 1A data. Land data, or 
Ocean data.* 

♦Data retrieved from permanent archival storage.* 

♦Request for data from the permanent archive.* 

♦information supplied to the Team Leader by the 
Team Members used to developed the Science 
Management Plan.* 

♦Data produced by the platform sensors that are used 
for operating the platform or as ancillary data.* 

♦Recently developed algorithms which have not been 
fully tested.* 

♦Specialized data products which have not yet been 
verified or validated.* 

♦immediate processing of designated data items 
without considering data item position in processing 
queues (cf. Routine Processing). Includes both Real- 
Time-Processing and Near-Real-Time-Processing.* 
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Priority-Ranked-Requests 

Processed-Data 

Processed-User-Rcquest 

Processing Algorithms 
Processing-Instructions 

Production-Report 

Production-Status-Inquiry 

Quick-Look-Science-Data 

Real-Time-Processing 

Received-CDHF-Data 

Received-Data 

Received-DHC-Data 

Received-Requests 

Reference-Monitoring-Profile 


•Received requests which the Team Leader has given 
priority ranking in concordance with the Science 
Management Plan. The Team Leader provides the 
schedule to the Team Members.* 

•Results of analyzing engineering data in real-time 
or trend analysis functions * 

•Data request that has been processed by the 
Receive-User-Request function and is used to locate 
and retrieve the data * 

*A mathematical procedure used by the CDHF or the 
TMCF to process the MODIS data. 

•Procedure and scheduling instructions that command 
the processing steps and the type of processing 
(routine, near-real-time, special, or reprocessing).* 

Production Schedule + 

Production Status 

•Request for a production report.* 

•A subset (up to 100%) of MODIS-Science-Data 
(Real-Time or Priority Playback) used to monitor 
MODIS instrument performance (may not be 
completely processed).* 

•Processing accomplished essentially as input data 
becomes available with only minimal storage delays 
for data buffering.* 

Data received by the CDHF (received DHC data, 
archive data products, processing algorithms, DQA 
criteria).* 

•Cataloged data stored at the TMCF’s used for 
algorithm development and validation/verification of 
data .* 

Level-0 data and ancillary data from the DHC that 
has been acceptance checked and reformatted and 
has had a header appended. 

•A TM data products request, TM observation 
request, or TM data processing request received by 
the Team Leader from Team Members in TMCF.* 

•Expected MODIS instrument engineering parameter 
levels annotated with limits at which alarm status 
should be declared.* 
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Requested-Data-Products 

Requested-Direct-Data 

Resource-Envelope 

Retransmission-Request 

Retrieved-Data 

Revised-Algorithms 

Routine-Processing 

Schedule-Data 

Science-Management-Plan 

Selected-Data-Products 

Selected-Science-Data 

Selected-Science-Data-Request 

Specialized-Data-Products 

Status-&-Trending-Data 


Data retrieved by the Process User Request function 
for distribution on a physical medium.* 

•Products generated on physical medium for 
distribution.* 

•Maximum allowable resource consumption levels for 
the MODIS instrument.* 

•Request for retransmission of data packets that do 
not meet quality standards* 

•Data retrieved from DADS storage by the 
Process-User-Request function to fill a product 
order .* 

•Algorithms which are tested and are ready for 
implementation.* 

•Processing that considers data item position in data 
processing queues. Cf. Priority Processing.* 

•English language descriptions of planned platform 
maneuvers or instrument operations.* 

•A plan which states the areas of responsibility, 
technical goals, and time tables of each Team 
Member, developed by the Team Leader and Team 
Members.* 

•Subsets of standard, near-real-time or specialized 
data product.* 

*A subset of MODIS-Science-Data or MODIS data 
products used to monitor MODIS instrument perfor- 
mance. These data are transmitted to the ICC by 
the CDHF to analyze past instrument performance 
and are not used for real-time monitoring.* 

*A request for selected science data for monitoring 
instrument performance.* 

•Data products which are considered part of a 
specific research investigation and are produced for 
a limited region or time period, or data products 
which are not accepted by the project as standard 
items.* 

♦instrument engineering and/or science data that has 
been analyzed to determine the operating status of 
the instrument and long-term trends. These data 
will be used to update any instrument models or 
algorithms used in analyzing engineering data.* 
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Stored-Data-Request 

Stored-Processed-Data 

TMCF-Observation-Request 

TMCF-Processing-Request 

TMCF-Request-Response 

TM-Data-Processing-Request 

TM-Data-Products-Request 

TM-Observation-Request 

User-Data-Parameters 

User-Observation-Request 

User-Processing-Request 

User-Product-Request 

User-Request 

User-Request-Response 

Valid-Observation-Sequence 


= Request for stored data from the CDHF temporary 
storage. 

= ’Data which has been processed in real-time and 
stored for analyzing long-term trends in 
performance.* 

= *A TM-Observation-Request after approval by the 
Team Leader.* 

= Standard-Processing-Requests + 

Reprocessing Requests (approved by Team Leader) + 
Specialized-Data-Processing-Request 

= *Response of the Team Leader to a 
TMCF-Processing-Request.* 

= *Team Member data processing request not yet 

approved by the Team Leader for general release.* 

* *Team Member data products request not yet 
approved by the Team Leader for general release.* 

= *Team Member observation request not yet approved 
by the Team Leader.* 

= ’Parameters used to locate and retrieve data to 
respond to a data request. Parameters used to 
identify data type, location, etc. in order to access 
the data* 

■ *A special observation request not included in the 
current schedule but consistent with general science 
objectives and the science mission plan.* 

* ’Request by a User to generate 
MODIS-Data-Products not previously available.* 

= ’Requests that distributed data products be delivered 
to a User from the MID ACS DADS.* 

- User Product Request + 

User Observation Request + 

User Processing Request. 

= ’Response to a user’s request.* 

= *A time-ordered sequence of instrument operations 
reflecting observation requests which have been 
determined to be consistent with the science plan, 
feasible from an orbit/geometry point-of-view and 
possibly coordinated with specific scenes .* 
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Verification/Validation-Study- = *Results of correlative and modeling studies.* 
Results 
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APPENDIX D 

MODIS DATA RATE AND VOLUME 


MOD IS INSTRUMENT 


OPERATION 



MODIS— N 

MODIS-T 


DAY 

NIGHT 

DAY NIGHT 

Number of Channels 

40 

15 

64 0 

7 . of Operation 

100 

100 

100 


STORED COMMAND REQUIREMENT 



MODIS-N 

MODIS-T 

No. of Mode change/day 

28 

28 

No. of Comd/Mode Change 

2 

2 

No. of Tilt Comd/day 

- 

644 

No. of Bytes/Comd. 

64 

64 

Total Bytes/day 

3,584 

44,800 

Total Bytes/week 

25,088 

313,600 

DATA RATES 



(Numbers in Mbps) 





MODIS-N 

MODIS-T TOTAL 


DAY 

NIGHT 

DAY 

NIGHT 

Instrument Data 

9.65 

1.54 

56 

0 

Calibration Info 

0.45 

0.08 

0. 15 

0 

Engineering Info 

0.01 

0.00 

0.01 

0 

Total 

10.11 

1.62 

6.72 


40 7 . Oversampling 

3.86 

0.62 

2.63 


Total 

13.97 

2.24 

9.35 



Average (No Oversampling) 5.87 3.36 9.23 

Average (Oversampling) 8.11 4.68 12.79 


Data Volume/Day 

Maximum : 140 Giga Bytes 
Minimum : 100 Giga Bytes 


MODIS data requires Grade II TDRSS service 
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APPENDIX E 

A FIRST-CUT AT MODIS DATA STORAGE AND PROCESSING REQUIREMENTS 


1 . 

2 . 


MODIS data 

rate: 9.23 Megabits/second (assume no oversampling) 

Data Level 

Path Lencrth 1 

Data Factor 1 

Data Volume 

Level-0 

3 

1.1 x Raw 

0.88 Terabits/day 

Level- 1A 

8 

1.1 x Level-0 

0.96 Terabits/day 

Level-IB 

12 

1.0 x Level- 1A 

0.96 Terabits/day 

Level-2 

20 

2.0 x Level-IB 

1.93 Terabits/day 

Level-3 

30 

.15 x Level-2 

0.29 Terabits/day 


1 From EosDIS Baseline Report Hay 26 Draft. 

3. 24 hours of data will be processed within 8 hours . 

4. Reprocessing will occur at twice the normal processing rate. 

5. Processor utilization will not exceed 70%. 


6 . 


7. 

8 . 


9. 

10 . 

11 . 


12 . 

13. 


Maintenance, near-real-time, browse, developmental, and other 


activities may add 40% of additional processing requirements. 
Constraints 3-6 require a contingency factor of 6 in proces- 


sing capacity. 


Data Level 


Basic 

Processing 

Capacity 


Contingency 

Processing 

Capacity 


Level-IA 

Level-IB 

Level-2 

Level-3 


89 MIPS 
134 MIPS 
447 MIPS 
100 MIPS 


536 MIPS 
804 MIPS 
2,680 MIPS 
603 MIPS 


Total 


770 MIPS 4,624 MIPS 


Store 1 week of data for processing on line. 
Store 2 weeks of data for reprocessing on line. 


Store 2 years of data off line (except for Level-0) . 


Store 1/2 year of data off line for reprocessing. 


Data Level 


On-Line 

Storage 

Capacity 


Off-Line 

Storage 

Capaci ty 


Level-0 

Level-IA 

Level-IB 

Level-2 

Level-3 


2.3 TBytes 
2.5 TBytes 
2.5 TBytes 
5.1 TBytes 
0.8 TBytes 


110 TBytes 
110 TBytes 
220 TBytes 
33 TBytes 


Total 


13.2 TBytes 473 TBytes 
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14. As we consider the MODIS data system architecture and system 
specifications, our task is to refine the rough estimates of path 
length, data volume ("factors"), and the amount of contingency 
allowance. The numbers outlined above provide a first very rough 
cut at the processing and storage requirements for the MODIS data 
system, which will be updated as we learn more about the proces- 
sing algorithms to be applied to the MODIS data. 
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